I have a situation where presentation of an X.509 certificate by a user in two-way SSL is considered authoritative for identification purposes, however I need to use the directory for attribute and authorization information. The LDAP server expects me to bind via my server certificate with two-way SSL. This is preferred in this environment over using a BindDN and password. By using +FakeBasicAuth*1, I was able to get the 1st step [search] working; however, mod_authnz_ldap automatically switches over to attempting a bind as the user in the compare step. In this case, it does so with the "pseudo-password" provided by FakeBasicAuth. [Obviously this fails.] The rest of the implementation is exactly what I neeed--it's only switch from anonymous/server bind to user bind that I need to change*2. I'd like to see a directive to mod_authnz_ldap that instructed it to use the same binding for the compare phase as it did for search. [I've also been looking at using ldaprc to see if TLS_ directives there can override application settings]. Has anyone else cracked this nut already, either with a "fork" of mod_authnz_ldap or their own module written on top of mod_ldap? --Pete ---- Configuration details: - Solaris (both x86 & sparc servers) - Apache 2.2.9 - OpenLDAP 2.3.41 ---- *1In this case we would need to make sure that an actual Basic Auth dialog was never presented; otherwise we could have users entering another user's DN by hand to masquerade as them. *2"Collapsing" the LDAP caches is another possible related optimization in this situation. If we are binding with the same credentials, we don't have to worry about polluting a cache with unauthorized data from another user's context. --------------------------------------------------------------------- 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
|