I've searched the mod_authnz documentation and also had already a look
into mod_authnz's sources to find an existing chance to configure some
kind of variable "bindDN-Pattern" but after reading both I understand
mod_authnz the way that it is mandatory to either use anonymous bind or
some kind of "proxy-user bind" (AuthLDAPBindDN) to search for an user's
DN (e.g. searching for uid/email) to bind to the LDAP server using the
found DN and the user provided password.
Have I missed something during my readings or is this an unsupported
feature?
For example apache's tomcat 5.5/6.0 JNDIrealm's configuration already
does provide a userPattern (please see
http://tomcat.apache.org/tomcat-6.0-doc/realm-howto.html#JNDIRealm and
search for "userPattern").
Please let me explain the background why there is a common demand for
such a mod_authnz feature:
Anonymous and even proxy-user based search request could harm a
company's restrictive data privacy policies. Therefore some directory
information tree (DIT) and LDAP server designs offer advanced but very
easy (for clients like mod_authnz) to implement/use approaches to offer
the administrator a chance to get rid of the need for proxy-user based
search but to be able to make an authorization decission directly in
each user's context.
As searching the user's branch seems not very harmful in regard to
privacy concerns searching the groups and their memberships is
definitively more "interesting". In modern directory
designs/implementations therefore an user's group membership is also
stored (as the DNs of the groups a distinct user is member of) directly
in each user's entry where the directory keeps track of the referential
integrity (which for example is supported by openldap). Thus there is no
need to expose the groups and their membership in general to any
service's proxy-user.
Instead, the authorization decision can be made directly using the
authenticated user's ldap connection as the user has been successfully
bind to the LDAP server before. Take for example this shortend LDIF
based user entry:
dn: uid=userA,dc=example,dc=com
uid: userA
memberOf: cn=groupA,dc=example,dc=com
memberOf: cn=groupB,dc=example,dc=com
memberOf: cn=groupC,dc=example,dc=com
IMHO there's no a need to prior search for "(uid=userA)" using a proxy
user in case the company's default policy is to just permit the uid for
login (instead of the eMail address for example) and use the user
provided uid to construct the bindDN which will be bind against the LDAP
server using the provided password. If the bind was successful the
user's connection (in this user's context) can be used to *compare* his
memberOf attribute against the authorized groupDN. Please note that an
LDAP server that only allows the "compare" operation on the memberOf
attribute (which can be enforced by LDAP server internal ACLs) will not
disclose any others of this user's group membership information to the
service (compare != search and compare != read) which fulfills most
restrictive privacy policies.
---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
" from the digest: users-digest-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org
