Re: [PATCH 48780] Input and improvements requested for suggested enhancement 48780
On Mon, Feb 22, 2010 at 11:46 AM, Thomas, Peter ptho...@hpti.com wrote: [ c.f. https://issues.apache.org/bugzilla/show_bug.cgi?id=48780 ] Eric Covener has commented, and I replied, to my suggested enhancement for mod_auth_ldap. In this case, I am attempting to use LDAP for authorization, accepting authentication from another provider--this would most typically be mod_ssl, but I've seen other in-family cases in Bugzilla's history where people are working to integrate SSO with other authentication providers such as Kerberos [or more generally GSSAPI]. The as-is implementation re-binds the LDAP connection using the user and password provided to perform the compare phase. The proposed patch adds a [non-default] option to the LDAP provider that causes the compare phase to occur without a user-specific re-binding. I haven't dug too deeply, but I didn't see how the attached patch changed the authorization-time behavior. Can you elaborate? -- Eric Covener cove...@gmail.com
RE: [PATCH 48780] Input and improvements requested for suggested enhancement 48780
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. --Pete -Original Message- From: Eric Covener [mailto:cove...@gmail.com] Sent: Monday, February 22, 2010 12:08 PM To: dev@httpd.apache.org Subject: Re: [PATCH 48780] Input and improvements requested for suggested enhancement 48780 On Mon, Feb 22, 2010 at 11:46 AM, Thomas, Peter ptho...@hpti.com wrote: [ c.f. https://issues.apache.org/bugzilla/show_bug.cgi?id=48780 ] Eric Covener has commented, and I replied, to my suggested enhancement for mod_auth_ldap. In this case, I am attempting to use LDAP for authorization, accepting authentication from another provider--this would most typically be mod_ssl, but I've seen other in-family cases in Bugzilla's history where people are working to integrate SSO with other authentication providers such as Kerberos [or more generally GSSAPI]. The as-is implementation re-binds the LDAP connection using the user and password provided to perform the compare phase. The proposed patch adds a [non-default] option to the LDAP provider that causes the compare phase to occur without a user-specific re-binding. I haven't dug too deeply, but I didn't see how the attached patch changed the authorization-time behavior. Can you elaborate? -- Eric Covener cove...@gmail.com
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
RE: [PATCH 48780] Input and improvements requested for suggested enhancement 48780
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
Re: [PATCH 48780] Input and improvements requested for suggested enhancement 48780
On Mon, Feb 22, 2010 at 12:33 PM, Thomas, Peter ptho...@hpti.com wrote: 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.] This should not be the case in 2.2.x and later, where we can call out individual authn and authz providers (and mix/match) explicitly. -- Eric Covener cove...@gmail.com
