Re: More flexible LDAP auth search filters?

From: Magnus Hagander <magnus(at)hagander(dot)net>
To: Mark Cave-Ayland <mark(dot)cave-ayland(at)ilande(dot)co(dot)uk>
Cc: Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: More flexible LDAP auth search filters?
Date: 2017-07-17 17:08:04
Message-ID: CABUevEyEQJiVmY+hxDORHkhSxz3Q96Q3XgCxUOL4BRuCLgOJzw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Jul 17, 2017 at 6:47 PM, Mark Cave-Ayland <
mark(dot)cave-ayland(at)ilande(dot)co(dot)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(at)hagander(dot)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.

--
Magnus Hagander
Me: https://www.hagander.net/ <http://www.hagander.net/>
Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2017-07-17 17:53:24 Re: Why have we got both largeobject and large_object test files?
Previous Message Stephen Frost 2017-07-17 16:59:48 Re: Why have we got both largeobject and large_object test files?