httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andreas Lindström <ant...@gmail.com>
Subject Authentication madness (a.k.a. suggestions?) regarding auth_basic and authn_alias
Date Wed, 02 Nov 2005 20:09:19 GMT
Here comes some suggestions for further development of
"mod_authn_alias" and also some suggestions for "mod_ldap" and
"mod_authnz_ldap":

I will give an example configuration at the end of this post just in
case i cant explain what i mean in a way that would make any sense to
anyone but me.

Why not use the "mod_authn_alias" module together with
"mod_auth_basic" for all authentication verification and
specification? (Only basic of course, digest is something else.) This
would be possible to do if you extend the functions of the modules a
bit (quite a bit actually). First off, including all connection
specific configuration options into the provider alias
("AuthnProviderAlias") would be a good idea. 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"

"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. This can
also be solved by enabling the use of several CA certs of the same
type for the "LDAPTrustedGlobalCert" configuration option, like this
example (this might already be possible, but i haven't tested it yet
as i don't have several LDAP servers running. If its already possible,
just ignore this part of the post):

  "LDAPTrustedGlobalCert CA_BASE64 certs/cacrt1.pem"
  "LDAPTrustedGlobalCert CA_BASE64 certs/cacrt2.pem"

Another way to solve it is to make "LDAPTrustedGlobalCert" connection
specific as well, but that seems a weee (a big weee) bit silly to me.

As for how to actually be able to specify all the needed configuration
values in in the configuration option "AuthnProviderAlias", i have no
idea. One way could be to give "AuthnProviderAlias" the same status as
"Directory", "Files" has right now. Another way could be to make
"AuthnProviderAlias" the only place where authentication information
may be used. As i said, i have no clue as how to do any of these
things so ill leave that to someone else to figure out.

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

The above statements would run all the "AuthnProviderAlias" by the
names specified and for each of them confirming if the authentication
is valid (1) or not valid (0). This would mean that each
"AuthnProviderAlias" has its own authority to verify users (or passing
the right to verify along to the correct verifier for the Require type
used). "mod_auth_basic" then runs its Satisfy option as
"(((1&0)|1)&!0&!0)==1" (for example), this resulting in a valid or non
valid authentication to the given resource.

Now here comes the promised example of a full configuration:

LDAPTrustedGlobalCert CA_BASE64 certs/ldap1.cacrt.pem
LDAPTrustedGlobalCert CA_BASE64 certs/ldap2.cacrt.pem

<AuthnProviderAlias ldap ldap1>
  LDAPTrustedMode SSL
  LDAPVerifyServerCert On
  LDAPTrustedClientCert CERT_BASE64 certs/ldap1.clientcrt.pem
  LDAPTrustedClientCert KEY_BASE64 certs/ldap1.clientkey.pem
  AuthLDAPBindDN "cn=username,ou=users,dc=foo1"
  AuthLDAPBindPassword "password"
  AuthLDAPURL ldaps://hostname1/ou=users,dc=foo1?cn?one
  AuthzLDAPAuthoritative Off
  AuthzUserAuthoritative On
  Require valid-user
  ErrorDocument 403 http://hostname/ldap1_error.php
</AuthnProviderAlias>

<AuthnProviderAlias ldap ldap2>
  LDAPTrustedMode TLS
  LDAPVerifyServerCert On
  LDAPTrustedClientCert CERT_BASE64 certs/ldap2.clientcrt.pem
  LDAPTrustedClientCert KEY_BASE64 certs/ldap2.clientkey.pem
  AuthLDAPBindDN "cn=username,ou=users,dc=foo2"
  AuthLDAPBindPassword "password"
  AuthLDAPURL ldap://hostname2/ou=groups,dc=foo2?cn?one
  AuthzLDAPAuthoritative Off
  AuthzGroupAuthoritative On
  Require group www1 www3
  ErrorDocument 403 http://hostname/ldap2_error.php
</AuthnProviderAlias>

<AuthnProviderAlias ldap ldap3>
  LDAPTrustedMode SSL
  LDAPVerifyServerCert Off
  AuthLDAPBindDN "cn=username,ou=users,dc=foo3"
  AuthLDAPBindPassword "password"
  AuthLDAPURL ldaps://hostname3/ou=users,dc=foo3?cn?one
  AuthzLDAPAuthoritative On
  Require ldap-user f00l1 f00l6
  ErrorDocument 403 http://hostname/ldap3_error.php
</AuthnProviderAlias>

<AuthnProviderAlias file file1>
  AuthUserFile /path/to/file
  AuthzUserAuthoritative On
  Require valid-user
  ErrorDocument 403 http://hostname/file1_error.php
</AuthnProviderAlias>

<AuthnProviderAlias file passwd>
  AuthUserFile /etc/passwd
  AuthzUserAuthoritative On
  Require valid-user
  ErrorDocument 403 http://hostname/passwd_error.php
</AuthnProviderAlias>

<Directory /foo>
  Order Deny,Allow
  Deny From All
  AuthType Basic
  AuthBasicProvider ldap1 ldap2 ldap3 file1 passwd
  AuthBasicAuthoritative On
  AuthName "woooow"
  Satisfy ((ldap1&file1)|ldap2)&!passwd&!ldap3
  ErrorDocument 403 http://hostname/error.php?auth_session=XXXX
</Directory>

I'm not sure this would be a good idea, but i can see the use for LDAP
based authentication. One LDAP server authenticates on user, one on
group, one on dn (for example), and then you use the "Directory"
Satisfy statement to see if the user has access or not, that way you
can set user auth based on several sources for one resource. And it
will also make the authentication system easier to use (as all
configuration options for authentication would be located in one place
only?), easier to understand (nah, not likely!), but it would make it
more flexible.

"All" and "Any" should of course still exist as keywords for Satisfy,
but i think the extended version of "Satisfy" might be really handy
for more complex systems that has to authorise based on several
sources. There is one big problem though, how do you get
"mod_authn_host" authorisation into that type of "Satisfy"?

As you also can see the "ErrorDocument" configuration option is in
both the "AuthnProviderAlias" and the "Directory" configuration
option. This will give admins the possibility of giving the user
different error messages based on what
failed during the authentication process, now this is a tricky bit,
how do you calculate which error message to show to the user? This
might not be the way it should be done at all, perhaps its better to
just use one error message in the resource configuration with an id
that identifies the authentication run that led to the failed auth and
then admins can check their logs for that id to see what went wrong?
Anyway, this is a part i havent yet figured out. Feel free to give
opinions.

And now, at the end... a possible inconsistency in the docs versus the
"mod_ldap" and "mod_authnz_ldap" modules, "LDAPTrustedClientCert"
doesnt work as the documentation says, you cant place it in a
"Directory" configuration options or the like. I think
"LDAPTrustedMode" has the same problem. (Verified on Apache 2.1.8, not
sure if it has been fixed for trunk as i still havent installed trunk
on my system.)

Oh, almost forgot, looking forward to opinions on this matter. Any. :)


Greets
  Andreas Lindström a.k.a Antel
  Sweden

Mime
View raw message