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 CABUevEz4rB4MHw=XF-DAPgrCFZP9jC2kFprZmWoDaJViRGmsKg@mail.gmail.com
Whole thread Raw
In response to [HACKERS] More flexible LDAP auth search filters?  (Thomas Munro <thomas.munro@enterprisedb.com>)
Responses Re: [HACKERS] More flexible LDAP auth search filters?
Re: [HACKERS] More flexible LDAP auth search filters?
List pgsql-hackers


On Thu, Jul 13, 2017 at 9:31 AM, Thomas Munro <thomas.munro@enterprisedb.com> wrote:
Hi hackers,

A customer asked how to use pg_hba.conf LDAP search+bind
authentication to restrict logins to users in one of a small number of
groups.  ldapsearchattribute only lets you make filters like
"(foo=username)", so it couldn't be done.  Is there any reason we
should allow a more general kind of search filter constructions?

A post on planet.postgresql.org today reminded me that a colleague had
asked me to post this POC patch here for discussion.  It allows custom
filters with ldapsearchprefix and ldapsearchsuffix.  Another approach
might be to take a filter pattern with "%USERNAME%" or whatever in it.
There's an existing precedent for the prefix and suffix approach, but
on the other hand a pattern approach would allow filters where the
username is inserted more than once.

Do we even need prefix/suffix? If we just make it "ldapsearchpattern", then you could have something like:

ldapsearchattribute="uid"
ldapsearchfilter="|(memberof=cn=Paris DBA Team)(memberof=cn=Tokyo DBA Team)"

We could then always to substitution of the kind:
(&(attr=<uid>)(<filter>))

which would in this case give:
(&(uid=mha)(|(memberof=cn=Paris DBA Team)(memberof=cn=Tokyo DBA Team)))


Basically we'd always AND together the username lookup with the additional filter.


Perhaps there are better ways to organise your LDAP servers so that
this sort of thing isn't necessary.  I don't know.  Thoughts?

I think something along this way is definitely wanted. We can argue the syntax, but being able to filter like this is definitely useful.

(FWIW, a workaround I've applied more than once to this in AD environments (where kerberos for one reason or other can't be done, sorry Stephen) is to set up a RADIUS server and use that one as a "middle man". But it would be much better if we could do it natively) 

--

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: [HACKERS] Adding -E switch to pg_dumpall
Next
From: Fabien COELHO
Date:
Subject: Re: [HACKERS] WIP Patch: Pgbench Serialization and deadlock errors