The AuthLDAPRemoteUserAttribute directive only works when authn processing goes through mod_authnz_ldap. If authn processing does not go through mod_authnz_ldap, but authz processing does go through, then this directive has no effect. I will attach a patch that enables the directive for authz-only processing, and ensures that the directive is only processed once if both authn and authz is encountered.
Created attachment 20303 [details] Patch for mod_authnz_ldap.c against svn trunk
I've developed this improvement independently, as I hit a real world example. We have a distributed authentication system with kerberos for authentication and ldap for authorization. So the user authenticates using GSSAPI or username/password. mod_auth_kerb passes the kerberos principal as user name, which includes the realm along with the real user name. Using the krb5Principal attribute as the key to search ldap allows me to find the correct entry. For the applications, however, we want the simple user name. For my modifications I copied even more strongly from the authentication function. You find "req->user = ..." in all these functions. After that the authentication does the following things before logging its success: 1. handle sec->user_is_dn resp. AuthLDAPRemoteUserIsDN 2. set AUTHENTICATE_* environment variables 3. handle sec->remote_user_attribute resp. AuthLDAPRemoteUserAttribute 4. sanity check that the requested attribute is really available I copied all these code fragments, as UserIsDN would be useful in an authorization-only scenario as well, more information in the environment might be useful to scripts (I replaced AUTHENTICATE with AUTHORIZE), and an error message in case of a missing attribute might help diagnosing errors. All this I copied after the "req->user = r->user" assignment at the end of the "if(!req)" block for authorization. I did my changes against the 2.2.x branch, where a single function handles authorization. Current trunk has four such functions, and exactly duplicate "if(!req)" blocks in each of these. That's a lot of code duplication; I didn't want to contribute to this by copying the stuff described above and pasting it four times. Instead I think this common code should be factored out, but I can't do this just now.
Created attachment 21247 [details] Different patch against 2.2.x branch Code copied from authn_ldap_check_password to authz_ldap_check_user_access in the 2.2.x branch. I'll work on merging this into trunk without too much code duplication when and if I find the time, if noone beats me to it.
Thanks for the patch! I'm using it on Apache 2.2.9 for a web app and with mod_dav_svn to allow single sign-on to our SVN repository.
I think the first patch writes to the per-directory config unsafely -- it is not per-request. Also, I think having the authorization handler overwrite r->user would have to be gated by a new directive.
(In reply to comment #5) > I think the first patch writes to the per-directory config unsafely -- it is > not per-request. > > Also, I think having the authorization handler overwrite r->user would have to > be gated by a new directive. I should elaborate that the "req" structure floating around in the right placs is per-request seems to be the proper place for this, and I'd be apt to commit a version that applied to trunk that didn't change behavior until a new directive were set. "req" existence can then tell you if ldap performed authn.
Created attachment 25999 [details] Patch against 2.2 ; allowing the use of custom_attribute as uid during authz phase and more
Here is a version against 2.2 correcting some bugs and issues earlier mentioned. I also added two new directives: -AuthLDAPRemoteFirstUserAttribute: By default, when using a remote user attribute, if there is more than one attributes of the same kind, mod_authnz_ldap returns as string made of all the attributes separated by a "; ". This can have some unwanted effects, for example. Apple's MacOS 10.6 Open Directory stores users and user aliases in LDAP as: dn: uid=jeanyves_avenard,cn=users,dc=m,dc=hydrix,dc=com uid: jeanyves_avenard uid: jean-yves.avenard objectClass: inetOrgPerson objectClass: posixAccount objectClass: shadowAccount objectClass: apple-user objectClass: extensibleObject objectClass: organizationalPerson objectClass: top objectClass: person remote_user attribute would therefore contain: "jeanyves_avenard; jean-yves.avenard" which is of no use. When AuthLDAPRemoteFirstUserAttribute is set, then only the first attribute will be returned. -AuthzLDAPRemoteUserAttribute: By default, the custom user attribute is only use for authentication. When AuthzLDAPRemoteUserAttribute is set, it will also be be used during authorisation. Cheers Jean-Yves Hydrix
Created attachment 26056 [details] Patch against 2.2 Update patch so AuthLDAPRemoteFirstUserAttribute is also used during authorization phase (useful when used in combination of mod_auth_kerb)