httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <>
Subject Re: Authentication madness (a.k.a. suggestions?) regarding auth_basic and authn_alias
Date Wed, 02 Nov 2005 20:38:43 GMT
Andreas Lindström wrote:
> Here comes some suggestions for further development of
> "mod_authn_alias" and also some suggestions for "mod_ldap" and
> "mod_authnz_ldap":
> [...] For example, these three
> configuration options (there are probably other configuration options
> that would have to be moved as well, but since I'm only up to date on
> the LDAP modules i will use those as examples):
>   "LDAPTrustedMode"
>   "LDAPTrustedClientCert"
>   "LDAPVerifyServerCert"

Yes, these should be connection specific, but I have a slightly alternate
proposal; what about

LDAPTrustedMode {ldap[s]://resource} on|off
LDAPTrustedClientCert {ldap[s]://resource} {type} {file}
LDAPTrustedServerCert {ldap[s]://resource} {type} {file}

Keep one -global- hash-by-resource for this information.  At configuration
time, dereference which hash entry corresponds to an LDAPURL mapping, and
mark that in the per-dir for quick lookup later on.

> "LDAPTrustedClientCert" really should be connection specific since you
> usually get a new cert for each new server you connect to. As for
> "LDAPTrustedMode", this configuration option would be handy to have on
> a connection basis since it is far from sure that all servers you
> connect to has support for the same transfer mode.
> And now for "LDAPVerifyServerCert", this option would be nice to have
> connection specific in case you have to access some servers that are
> maintained by someone else who is not using the same CA cert.

Yup.  None of these are global, specific to one server.

>   "LDAPTrustedGlobalCert CA_BASE64 certs/cacrt1.pem"

Some global default would be good, or we could simply use the directives
mentioned above with an empty or 'default' first argument.  Note one
thing you hinted at in the IRC channel; we should *never* have the
multiple choices, and fail over, on the same backend.  If the user
misconfigures - then it should fail!  It's far to expensive to try
multiple times to connect to a single ldap backend resource provider.
Configure it once, and configure it correctly, or get some feedback
from the error log of what you had done wrong.

> Now for the fun part, the main part, since "AuthBasicProvider" already
> takes several different authentication providers, which it then tries
> one after another until one works... why not extend that so it runs
> all the provided provider names by default and then extend the
> "Satisfy" key one step further too? An example:
>   "AuthBasicProvider ldap1 ldap2 ldap3 file1 passwd"
>   "Satisfy (((ldap1&file1)|ldap2)&!passwd&!ldap3)"

Of course the suggestions above wouldn't interfere with chaining or otherwise
improving ldap providers, it would just lift the ssl characteristics of one
ldap resource out from the current, confusing situation.


View raw message