Re: [HACKERS] More flexible LDAP auth search filters? - Mailing list pgsql-hackers
| From | Magnus Hagander |
|---|---|
| Subject | Re: [HACKERS] More flexible LDAP auth search filters? |
| Date | |
| Msg-id | CABUevEyEQJiVmY+hxDORHkhSxz3Q96Q3XgCxUOL4BRuCLgOJzw@mail.gmail.com Whole thread Raw |
| In response to | Re: [HACKERS] More flexible LDAP auth search filters? (Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>) |
| Responses |
Re: [HACKERS] More flexible LDAP auth search filters?
|
| List | pgsql-hackers |
On Mon, Jul 17, 2017 at 6:47 PM, Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> wrote:
-- On 17/07/17 13:09, Magnus Hagander wrote:
Hi Magnus,
Great to hear from you! It has definitely been a while...
Indeed. You should spend more time on these lists :P
> Generally you find that you will be given the option to set the
> attribute for the default search filter of the form
> "(attribute=username)" which defaults to uid for UNIX-type systems and
> sAMAccountName for AD. However there is always the ability to specify a
> custom filter where the user is substituted via e.g. %u to cover all the
> other use-cases.
>
> Right, but that's something we do already today. It just defaults to
> uid, but it's easy to change.
Yes, I think that bit is fine as long as the default can be overridden.
There's always a choice as to whether the defaults favour a POSIX-based
LDAP or AD environment but that happens with all installations so it's
not a big deal.
It's easy enough to change.
> As an example, I don't know if anyone would actually do this with
> PostgreSQL but I've been asked on multiple occasions to configure
> software so that users should be allowed to log in with either their
> email address or username which is easily done with a custom LDAP filter
> like "(|(mail=%u)(uid=%u))".
>
>
> How would that actually work, though? Given the same user in ldap could
> now potentially match multiple different users in PostgreSQL. Would you
> then create two accounts for the user, one with the uid as name and one
> with email as name? Wouldn't that actually cause more issues than it solves?
Normally what happens for search+bind is that you execute the custom
filter with substitutions in order to find the entry for your bind DN,
but you also request the value of ldapsearchattribute (or equivalent) at
the same time. Say for example you had an entry like this:
dn: uid=mha,dc=users,dc=hagander,dc=net
uid: mha
mail: magnus@hagander.net
Using the filter "(|(mail=%u)(uid=%u))" would locate the same bind DN
"uid=mha,dc=users,dc=hagander,dc=net" with either one of your uid or
email address.
If the bind is successful then the current user identity should be set
to the value of the ldapsearchattribute retrieved from the bind DN
entry, which with the default of "uid" would be "mha". Hence you end up
with the same user role "mha" regardless of whether a uid or email
address was entered.
Right. This is the part that doesn't work for PostgreSQL. Because we have already specified the username -- it goes in the startup packet in order to pick the correct row from pg_hba.conf.
I guess in theory we could treat it like Kerberos or another one of the systems where we get the username from an external entity. But then you'd still have to specify the mapping again in pg_ident.conf, and it would be a pretty strong break of backwards compatibility.
In terms of matching multiple users, all LDAP authentication routines
I've seen will fail if more than one DN matches the search filter, so
this nicely handles the cases where either the custom filter is
incorrect or more than one entry is accidentally matched in the directory.
So do we, in the current implementation. But it's a lot less likely to happen in the current implementation, since we do a single equals lookup.
pgsql-hackers by date: