httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brad Nicholes" <BNICHO...@novell.com>
Subject Re: Multiple AAA providers
Date Fri, 04 Mar 2005 15:56:49 GMT
Actually I think the better syntax would be:

<AuthProviderAlias ldap Myldap1>
   ...config options for mod_authnz_ldap...
</AuthProviderAlias>

<AuthProviderAlias ldap Myldap2>
   ...config options for mod_authnz_ldap...
</AuthProviderAlias>

<AuthProviderAlias file Myfile1>
   ...config options for mod_auth...
</AuthProviderAlias>

<Location /foo1>
   AuthProvider Myldap1 Myfile1
   ...Other config options...
</Location>
<Location /foo2>
   AuthProvider Myldap2 Myfile1
   ...Other config options...
</Location>
<Location /foo3>
   AuthProvider Myldap1 Myldap2
   ...Other config options...
</Location>

This would allow you to mix-match-reuse-redefine auth configurations
anywhere you like.  I haven't thought this through completely from an
implementation standpoint, but by moving the provider definitions into
mod_auth_basic and then extending the framework for handling multiple
provider definitions into the providers themselves, I think we can come
out with something very useful and reuseable.

Brad

>>> minfrin@sharp.fm Friday, March 04, 2005 1:06:47 AM >>>
Justin Erenkrantz said:

> I still maintain the better way to do this is to handle it in the
provider
> modules themselves by leveraging the provider API instead.
>
> To reiterate, in my mind, the ideal syntax is:
>
> <Location /foo>
>   <LDAPProvider ldap1>
>       ...config options for mod_authnz_ldap...
>   </LDAPProvider>
>   <LDAPProvider ldap2>
>       ...config options for mod_authnz_ldap...
>   </LDAPProvider>
>   <DBDProvider my_db>
>       ...config options for hypothetical mod_authn_dbd...
>   </DBDProvider>
>
>   ...config options for mod_authnz_ldap...
>
>   AuthUserFile conf/foo
>
>   AuthBasicProvider ldap1 ldap2 ldap file my_db
> </Location>
>
> This isolates the config directly to the module, and if we so desire,
we
> could
> add helper functions which promote re-use of this strategy by other
> provider
> modules as needed.  -- justin

This means that:

- Every auth module has to be independantly updated to use this method
(which won't happen)
- Every module will have it's own method of configuring multiple
providers.

Putting my end user hat on, doing it the way you suggest would irritate
me
no end, as it would make no logical sense to me why one auth provider
allows multiple configurations and another doesn't, or why one auth
provider uses one config mechanism and another auth provider uses a
different one.

I definitely think that getting the auth framework to understand this
syntax is the right way to go, we just need to figure out that "magic
syntax" that will work elegantly.

Regards,
Graham
--


Mime
View raw message