httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andreas Lindström <ant...@gmail.com>
Subject Re: Authentication madness (a.k.a. suggestions?) regarding auth_basic and authn_alias
Date Thu, 10 Nov 2005 18:19:45 GMT
On 11/2/05, William A. Rowe, Jr. <wrowe@rowe-clan.net> wrote:
> 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.

Yes, i agree. This would be a good way to solve it. However,
LDAPTrustedMode really should indicate which type of connection should
be used, and not just on or off.

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

Agreed. But this also demands LDAPTrustedMode to indicate None, TLS or
SSL, not just on or off. The LDAP server doesnt support TLS over port
636 for example so its important that we can separate them. The option
LDAPVerifyCert should be included too, using on or off values
(possibly the same values as LDAP clients uses... never, allow, try,
demand), as this could be used to implement the verification of
clients if its needed.

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

Ok, since there is major discussion about access, auth, authz, authn
and authnz atm i just thought i should bring this thread up again
since i really didnt get any responses last time. What i tried to
explain in my first post here is an idea that basically adds
authn_alias as an abstract authorization layer. Each of the different
authn(z?) modules is used to specify different authorization clauses
using authn_alias and then those clauses are used in
AuthBasicProvider.

Other than this you extend the Satisfy option to implement a list of
clauses separated by logical operators which then is used to calculate
a global access value for the directory where the Satisfy clause is
specified. (all clauses are run and calculated by default)

(See the first post for a more thorough explanation)

One thing about this implementation though, it cannot use host
authorization as it is used atm. It has to be made into the same type
of modules as all the rest of the modules. Honestly, i think it would
be a good idea to remake the host auth into a module that follows the
patterns of all the rest anyway... it would make the discussion in one
of the other threads obsolete as it would definitely be called authz
then. Plus, it would remove some confusion from the current auth
system...

If you wanted to remove all confusion from the system then you do the
above and then rename mod_authn_alias into mod_auth and specify that
it is the only module that is used to build auth clauses (as used in
AuthBasicProvider, or possibly renamed to AuthProvider if you change
the usage and name of mod_authn_alias too). This would enable users to
use both auth_basic and auth_digest and any auth providers they wanted
in one Directory authorization. (But that is a drastic change, it
could be a good idea to clarify the situation in some way at least...
if the developers cant agree on a correct naming or possibly not
understand the layout... how do you think a user will see the
situation?)

Anyway, for an example configuration, see my first post in this thread.

/ Andreas

Mime
View raw message