Lars Kruse
2010-01-25 12:00:09 UTC
Hi,
the attached patch adds a second option for non-anonymous binds to the
authnz_ldap module. Please consider it for adoption.
The current situation:
The authnz_ldap module supports only one kind of non-anonymous bind to the ldap
server: by specifying the username ("binddn") and password ("bindpw") in an
apache config file. This is obviously not a very pretty thing, since you need
to take good care for file permissions (as an admin) and also users may feel a
little bit uncomfortable to put their plaintext login data into an htaccess
file.
Use cases where anonymous binds don't work:
1) The most common use case for non-anonymous binds is an Active Directory
server, that (by default) does not accept anonymous binds. Usually this is
solved by creating a specific ldap user with limited read access and putting
its credentials into the apache config file. See examples:
http://www.held-im-ruhestand.de/software/apache-ldap-active-directory-authentication
http://www.jejik.com/articles/2007/06/apache_and_subversion_authentication_with_microsoft_active_directory/
2) My specific use case are some servers, that provide various services (mail,
webspace, wikis, svn, ...) to different people. All accounts are managed in a
single LDAP database. Since privacy is important for our users, it is not
acceptable, that they can get a complete user list from the ldap server. Thus
the servers, that offer shell access or webspace to users may not bind to the
LDAP server anonymously and even authenticated users may only access their own
accounts within the ldap database.
In this setup we can't use the authnz_ldap module, since we need
authenticated binds, but we don't want our users to store their precious
credentials in a plain text file.
One way of solving this issue is already implemented in Muquit's "mod_auth_ldap"
(http://www.muquit.com/muquit/software/mod_auth_ldap/mod_auth_ldap_apache2.html).
There the respective option is called "AuthOnBind".
The patch, that I attached (not based on Muquit's code), allows the following:
- a user tries to log into an apache-served location, that requires
authentication
- the given credentials (username and password) are combined with the "basedn"
and "attrib" value (defined in "AuthLDAPUrl")
- the authnz_ldap module uses these credentials to bind to the server
(for authentication and authorization)
The above behaviour is triggered by a new configuration directive, that I named
"AuthLDAPAuthOnBind". It defaults to "off", thus nothing changes for current
configurations.
This new behaviour covers the two use cases described above (even though I did
not check it in an Active Directory setup).
The patch is currently in use in our setup (see use case (2) above) and it runs
without problems.
Regarding the code quality:
I am not used to the apache codebase, thus I am not sure, if I used the string
functions in the proper way (around line 387). Please comment, if I overlooked
something!
cheers,
Lars
PS: I just e-mailed a signed "Individual Contributor License Agreement" to
***@apache.org - I am not sure, if this is necessary - just to let you
know ...
the attached patch adds a second option for non-anonymous binds to the
authnz_ldap module. Please consider it for adoption.
The current situation:
The authnz_ldap module supports only one kind of non-anonymous bind to the ldap
server: by specifying the username ("binddn") and password ("bindpw") in an
apache config file. This is obviously not a very pretty thing, since you need
to take good care for file permissions (as an admin) and also users may feel a
little bit uncomfortable to put their plaintext login data into an htaccess
file.
Use cases where anonymous binds don't work:
1) The most common use case for non-anonymous binds is an Active Directory
server, that (by default) does not accept anonymous binds. Usually this is
solved by creating a specific ldap user with limited read access and putting
its credentials into the apache config file. See examples:
http://www.held-im-ruhestand.de/software/apache-ldap-active-directory-authentication
http://www.jejik.com/articles/2007/06/apache_and_subversion_authentication_with_microsoft_active_directory/
2) My specific use case are some servers, that provide various services (mail,
webspace, wikis, svn, ...) to different people. All accounts are managed in a
single LDAP database. Since privacy is important for our users, it is not
acceptable, that they can get a complete user list from the ldap server. Thus
the servers, that offer shell access or webspace to users may not bind to the
LDAP server anonymously and even authenticated users may only access their own
accounts within the ldap database.
In this setup we can't use the authnz_ldap module, since we need
authenticated binds, but we don't want our users to store their precious
credentials in a plain text file.
One way of solving this issue is already implemented in Muquit's "mod_auth_ldap"
(http://www.muquit.com/muquit/software/mod_auth_ldap/mod_auth_ldap_apache2.html).
There the respective option is called "AuthOnBind".
The patch, that I attached (not based on Muquit's code), allows the following:
- a user tries to log into an apache-served location, that requires
authentication
- the given credentials (username and password) are combined with the "basedn"
and "attrib" value (defined in "AuthLDAPUrl")
- the authnz_ldap module uses these credentials to bind to the server
(for authentication and authorization)
The above behaviour is triggered by a new configuration directive, that I named
"AuthLDAPAuthOnBind". It defaults to "off", thus nothing changes for current
configurations.
This new behaviour covers the two use cases described above (even though I did
not check it in an Active Directory setup).
The patch is currently in use in our setup (see use case (2) above) and it runs
without problems.
Regarding the code quality:
I am not used to the apache codebase, thus I am not sure, if I used the string
functions in the proper way (around line 387). Please comment, if I overlooked
something!
cheers,
Lars
PS: I just e-mailed a signed "Individual Contributor License Agreement" to
***@apache.org - I am not sure, if this is necessary - just to let you
know ...