httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Erenkrantz <>
Subject Re: authentication rewrite
Date Tue, 27 Aug 2002 06:44:32 GMT
On Tue, Aug 27, 2002 at 12:46:17AM -0400, John K. Sterling wrote:
> Hmm -
> My biggest concern here is that you are now adding another layer of 
> abstraction on the apache api.  It seems nice in theory, but it is not 
> very extensible.  If this were to be going in only for the simple auth 
> modules we currently support (which are almost never changed or 
> augmented) i suppose it wouldn't be a big deal.  The ldap module, 

My point is that I need to add another front end authentication
module (namely within mod_dav).  I think it'd be pointless to
duplicate all of the backend work done in mod_auth* so that
mod_dav can authenticate users.  The current authentication API
can't work as it combines the front and back-ends.  The answer we
give to people is, "cut-and-paste."  Ick.  Therefore, yes, I think
we have to introduce another level as what we have now is

Currently, most of the code in mod_auth_dbm is just a duplication of
mod_auth.  mod_auth_digest does not support anything other than flat
files.  This would remove code duplication and add features where the
code wasn't duplicated.  I see this as a win just from porting the
'simple' modules over to a scheme like this.  Nevermind mod_dav.

And, it doesn't mandate that third-party modules have to move to this
scheme - it's opt-in.

> however, may 1: not want to return all groups a user is in (as opposed 
> to letting the directory perform a search for us) and 2: may want more 
> complex control of requirements (e.g. property limitations etc.) - I 
> find it clean in theory, but ironically cumbersome in practice to try 
> to simplify the auth api like this -

In my vision, the LDAP module would have its own directives/options
to specify what it returns.  So, I don't think this is a big concern.

I'd imagine something like:

AuthProvider ldap
AuthLDAPUserSearch (username=%s)
AuthLDAPGroupSearch (groupmember=%s)

Ideally, you could use the LDAP filters that most PAM implementations
use, but definitely allow the user to tweak them.  I'd like to get
mod_auth_ldap ported to this, and if we move towards a provider-based
system, I think mod_auth_ldap should be moved back into the core.
(Namely because that's the preferred auth for DAV ACL support as it
is hierarchical.)

Of course, I would expect the API to become better as we play with it
more and determine what is missing.  However, this API is currently
sufficient for the two providers that are already included - enough
so that I think future work warrants inclusion in the tree.  As we
add mod_dav support, we may need more to add more functions, but the
point is that this API is extensible.

> maybe abstracting out some of the logic into re-usable libraries would 
> work, but layering callback structures like this is IMO not the way to 
> go.

My point is that we need to 'layer callback structures' like this
to allow other modules to reuse the authentication backends.
Currently, our authentication design doesn't allow for reuse.

If we were to code it up as 're-usable libraries', we wouldn't allow
them to define their own directive syntax like my proposed solution
would.  So, I think there is a benefit for making these providers
modules in their own right - they just don't implement the access
hooks.  But, by being modules, it allows them flexibility in how
they are configured that they wouldn't ordinarily have.  -- justin

View raw message