Re: [HACKERS] More flexible LDAP auth search filters? - Mailing list pgsql-hackers

On 17/07/17 18:08, Magnus Hagander wrote:

> On Mon, Jul 17, 2017 at 6:47 PM, Mark Cave-Ayland
> <mark.cave-ayland@ilande.co.uk <mailto:mark.cave-ayland@ilande.co.uk>>
> wrote: 
>     Great to hear from you! It has definitely been a while...
> 
> Indeed. You should spend more time on these lists :P

Well I do get the emails, unfortunately it's trying to find the time to
read them all ;)

>     > 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 <mailto: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 don't think that's necessarily going to be an issue here because if
you're specifying a custom LDAP filter then there's a very good chance
that you're delegating access control to information held in the
directory anyway, e.g.
 (&(memberOf=cn=pgusers,dc=groups,dc=hagander,dc=net)(uid=%u))
 ((&(uid=%u)(|(uid=mha)(uid=mark)(uid=thomas)))

In the mail example above when you're using more than one attribute, I
think it's fair enough to simply say in the documentation you must set
user to "all" in pg_hba.conf since it is impossible to know which
attribute is being used to identify the user role until after
authentication.

I should add that personally I don't recommend such setups where the
user can log in using more than one identifier, but there are clients
out there who absolutely will insist on it (think internal vs. external
users) so if the LDAP support is being updated then it's worth exploring
to see if these cases can be supported.

> 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.

(goes and glances at the code)

Is there no reason why you couldn't just overwrite port->user_name based
upon ldapsearchattribute at the end of CheckLDAPAuth?

And if this were only enabled when a custom filter were specified then
it shouldn't cause any backwards compatibility issues being a new feature?

>     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.

Great, that's absolutely fine :)


ATB,

Mark.