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.
Bill
