Yes, I believe this patch would do that so long as the user name passed by the other authentication provider in conjunction with the options to the LDAP provider brings back one-and-only-one result for valid users. Maybe we don't need to make all those checks and references against mod_ssl I discussed, but rather create a new authentication provider, e.g. "mod_authn_ssl" that does more than just pass a user name and password as mod_ssl's +FakeBasicAuth does, but actually fully authenticates the user, without authorizing them. Is this what you were getting at in your original comment?
Even if we do this, we * still * need this patch or something like it to tell the LDAP provider that it should only perform authorization, and not authentication. [Effectively we would be telling it to start with the compare phase, and do so WITHOUT binding as the user.] --Pete -----Original Message----- From: Eric Covener [mailto:cove...@gmail.com] Sent: Monday, February 22, 2010 12:23 PM To: dev@httpd.apache.org Subject: Re: [PATCH 48780] Input and improvements requested for suggested enhancement 48780 On Mon, Feb 22, 2010 at 12:15 PM, Thomas, Peter <ptho...@hpti.com> wrote: > The beauty is that it doesn't change the authorization behavior, except to > the extent that the bind-as-user is bypassed if the option is set. I only > found one location that attempted to validate the user's password, so I > surmized that was the 2nd [compare] operation, and I used the "get user DN" > variant which--according to the mod_ldap documentation, verified by my visual > inspection--is a copy of "check user cert" without the user bind. > But wouldn't that mean LDAP authorization + any other authentication provider would be working today? -- Eric Covener cove...@gmail.com
