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=comIMHO 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-unsubscribe@xxxxxxxxxxxxxxxx " from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
|