Re: Mod_auth_external (fwd)

[Dirk-Willem van Gulik <di...@elect6.jrc.it>]

---------- Forwarded message ----------
Date: Wed, 19 Nov 1997 11:51:37 +0100 (CET)
From: "Dirk-Willem van Gulik <di...@elect6.jrc.it>" <di...@cils.plazza.it.>
Cc: new-httpd@apache.org
Subject: Re: Mod_auth_external



On Wed, 19 Nov 1997, Brian Behlendorf wrote:

> help, info overload.  If someone wants to response, maybe Dirk as he's done
> the most creative auth stuff, I would appreciate it.  Thanks!

I'll contacted the guy. It is indeed a very neat piece of work; but easily
interferese really deep with apache... perhaps something for version 3.0
as it kind of puts our two layer auth model in distress. (auth and
access) We either need three levels or just one generic one.

The second problem is speed; the levels of abstraction cause extra bloat 
in the code: on not-so-scientific test saw response dropping from some
1500 auths/second to less than 30.. i.e. at least one order of
magnitude Something not acceptable for say a newspaper application.

On the other hand I _H_A_T_E_ the current situation with 80 percent
shared code and comments between

	mod_auth
	mod_auth_*dbm
	mod_auth_*cookie
	mod_auth_*sql
	mod_auth_pem, digest, etc...

	and so on..

But in short, neat and interesting work. I'll report back to the list when
I understand a bit more.

Worth investigating.

Dw.

> >I have been using Nathan Neulinger�s mod_auth_external module for a web
> >application, writing my own authenticator to authenticate against a Solid
> >SQL server. Doing that i started thinking (a bad habit of mine... ) I sent
> >him an email describing some of my thoughts and he responded that I should
> >try forwarding it to the Apache maintainers. I hope you fit that category
> >or at least would be so kind to forward this mail to the right person.
> >
> >Here is some of my thoughts :
> >
> >+) Calling af an external authenticator is a great way og doing
> >authentication against more sophisticated sources than just a passwordfile
> >-) But the overhead involved in starting up the new process could be
> >removed
> >-) Every access to a protected directory does an authentication call, an
> >SQL authenticator could therefor be more efficient if it was able to do
> >caching of the data from the DB-server, but this would require the
> >authenticator to be persistent.
> >-) The current scheme to do external authentication using mod_auth_external
> >doesn�t  allow the authenticator to be persistent and therefor it cannot
> >maintain connections to databases - the Solid server in my example.
> >+) External authentication removes the need for more exotic Apache modules,
> >that way the apache source and the httpd is able to be a more "clean" httpd
> >- that way removing possible errors.
> >+) External authentication removes any need for linking the apache
> >executable with different libraries used in the authentication module -
> >again this leeds to a more clean and stable binary.
> >
> >By doing authentacation with an external, dedicated program new
> >possibilities arises - all diferent kinds of smart authentication mecanisms
> >is made possible :
> >
> >*) Authentication based on date/time
> >*) Authentication based on radius or tacacs
> >*) Authentication based on PAM or traditional unix passwd/shadow files
> >*) Authentication and registration in an external database
> >*) And a lot more...
> >
> >Doing more resource intensive/security critical authentications on the
> >actual host running the httpd can lead to security considerations. Being
> >able to do authentication in a distributed way could help improve security.
> >And on a network with multiple httpd-hosts one host running the distributed
> >approach can lead to network-wide resource savings and to a consistent
> >authentication scheme across the network.
> >
> >My idea for a solution is a socket based two-tier model with an apache
> >module calling the authenticator on the same or a different host,
> >and then letting that authenticator do whatever clever tings the actual
> >implementation requires such as maintaining a connection to a databse
> >server, caching information etc.
> >
> >This will of course need to implement a standarized protocol used in the
> >apache->authenticator communication. Such a protocol would have to be
> >relative secure, extensible and well-defined. And it could pass different
> >data from the httpd to the authenticator susch as remote IP addr and other
> >things possible relevant for the authentication process.
> >
> >
> >Please let me know what you think of this. I would like to code it myself,
> >but I think it is better with some discussion first istead of developing in
> >the wrong direction.
> >So I really wan�t to get in contact with the right people on this issue.
> >
> >
> >
> >Stephen Aaskov
> >DDK - Dansk Data Kommunikation
> >
> >
> >
> --=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
> "it's a big world, with lots of records to play." - sig   brian@organic.com
> 

Re: Mod_auth_external (fwd)

[Dean Gaudet <dg...@arctic.org>]

On Wed, 19 Nov 1997, Dirk-Willem van Gulik wrote:

> On the other hand I _H_A_T_E_ the current situation with 80 percent
> shared code and comments between
> 
> 	mod_auth
> 	mod_auth_*dbm
> 	mod_auth_*cookie
> 	mod_auth_*sql
> 	mod_auth_pem, digest, etc...
> 
> 	and so on..
> 
> But in short, neat and interesting work. I'll report back to the list when
> I understand a bit more.

At the beginning of the summer Ian Kluft proposed a solution to this
through an API change.  The change goes like this:

- a "module" supplies the various configuration hooks such as the
dir/server create/merge functions, the init/child_init/child_exit
functions, and a command vector

- a "request handling module" is a "module" which also supplies the
various phase handlers

- a "db module" is a "module" which also supplies various db lookup
primitives such as "fetch" and "store" (by key).

Then mod_auth is written to use an arbitrary db_module. 

Note that although the above has inheritence in it, it's not enough in my
books to scream "C++".  Really all this has is three interfaces, and
modules have to provide the first interface, and can optionally provide
either of the other two interfaces.

This is definately something that needs to be done in 2.0. 

Dean