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:[email protected]] Sent: Monday, February 22, 2010 12:23 PM To: [email protected] Subject: Re: [PATCH 48780] Input and improvements requested for suggested enhancement 48780 On Mon, Feb 22, 2010 at 12:15 PM, Thomas, Peter <[email protected]> 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 [email protected]
