| Summary: | Binding with user-supplied credentials | ||
|---|---|---|---|
| Product: | Apache httpd-2 | Reporter: | drotiro |
| Component: | mod_authz_ldap | Assignee: | Apache HTTPD Bugs Mailing List <bugs> |
| Status: | RESOLVED FIXED | ||
| Severity: | enhancement | CC: | margol |
| Priority: | P2 | Keywords: | FixedInTrunk, PatchAvailable |
| Version: | 2.2.14 | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | All | ||
| Attachments: | the proposed patch | ||
Out of curiousity, what do your basic auth usernames look like and what LDAP backends do they authenticate with? I think some kind of munging is necessary in the common case to be able to have something you can bind with. We use uid as usernames for the authentication (search phase). Then I use the user dn fetched this way - and not the username - for authorization (compare phase). This is very similar to setting the directive 'AuthLDAPBindDN', but dinamically, so no munging is necessary. Btw, we use lotus notes' ldap. (In reply to comment #1) (In reply to comment #0) > Created an attachment (id=24671) [details] > the proposed patch > I'm proposing a patch to use the username and password entered by the user in > the compare phase. > It does something similar to #43792, but differently: > - it uses the dn retreived from server, instead of appending a suffix to > username > - it saves the password in authn_ldap_request_t, as long as needed then wipes > it > It adds a new configuration flag: AuthLDAPBindAsUser > The flag defaults to off, when set to 'on' enable the bind as user behaviour > The patch is against 2.2.14. I'm wondering what we're accomplishing by doing the authorization with the bound user? We're already using the config-supplied DN and password to bind during the authentication phase, and your patch still requires authentication to be provided by mod_authnz_ldap (to cache the password for the authorization bind), so what are we gaining by binding as the user only in the latter phase? It's a bit confusing as at first read, I'd assumed that you were talking about the authentication bind, which would have made more sense, albeit would need to be documented as being as potentially dangerous as HTTP basic auth over the network (although this refers to the backend network), unless a secure connection to the LDAP server was used. > I'm wondering what we're accomplishing by doing the authorization with the
> bound user? We're already using the config-supplied DN and password to bind
> during the authentication phase, and your patch still requires authentication
> to be provided by mod_authnz_ldap (to cache the password for the authorization
> bind), so what are we gaining by binding as the user only in the latter phase?
>
Reporter has an LDAP server that allows anonymous searches but does not allow anonymous compares [rather it's configured that way]. So he leaves off the bind dn/password to retrieve the DN, but can't do certain types of authz anonymously.
If I commit the patch, I will make the directive sound less general and put some time into the doc.
(In reply to comment #4) > Reporter has an LDAP server that allows anonymous searches but does not allow > anonymous compares [rather it's configured that way]. So he leaves off the > bind dn/password to retrieve the DN, but can't do certain types of authz > anonymously. > > If I commit the patch, I will make the directive sound less general and put > some time into the doc. If there's a use-case, I'm +1 committed a variant of your patch to trunk in r950248. fixed in 2.4.1 |
Created attachment 24671 [details] the proposed patch I'm proposing a patch to use the username and password entered by the user in the compare phase. It does something similar to #43792, but differently: - it uses the dn retreived from server, instead of appending a suffix to username - it saves the password in authn_ldap_request_t, as long as needed then wipes it It adds a new configuration flag: AuthLDAPBindAsUser The flag defaults to off, when set to 'on' enable the bind as user behaviour The patch is against 2.2.14.