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

From Thomas Munro
Subject Re: [HACKERS] More flexible LDAP auth search filters?
Date
Msg-id CAEepm=33ALVcJ1OzrNm4xs4ns-1GhhAFw1FT9tEjjm=ouOWxFw@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] More flexible LDAP auth search filters?  (Magnus Hagander <magnus@hagander.net>)
Responses Re: [HACKERS] More flexible LDAP auth search filters?
Re: [HACKERS] More flexible LDAP auth search filters?
List pgsql-hackers
On Fri, Jul 14, 2017 at 11:04 PM, Magnus Hagander <magnus@hagander.net> wrote:
> On Thu, Jul 13, 2017 at 9:31 AM, Thomas Munro
> <thomas.munro@enterprisedb.com> wrote:
>> 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.

Ok, so we have 3 ideas put forward:

1.  Wrap username with ldapsearchprefix ldapsearchsuffix to build
filter (as implemented by POC patch)
2.  Optionally AND ldapsearchfilter with the existing
ldapsearchattribute-based filter (Magnus's proposal)
3.  Pattern-based ldapsearchfilter so that %USER% is replaced with
username (my other suggestion)

The main argument for approach 1 is that it follows the style of the
bind-only mode.

With idea 2, I wonder if there are some more general kinds of things
that people might want to do that that wouldn't be possible because it
has to include (attribute=user)... perhaps something involving a
substring or other transformation functions (but I'm no LDAP expert,
that may not make sense).

With idea 3 it would allow "(|(foo=%USER%)(bar=%USER%))", though I
don't know if any such multiple-mention filters would ever make sense
in a sane LDAP configuration.

Any other views from LDAP-users?

-- 
Thomas Munro
http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Alexander Korotkov
Date:
Subject: Re: [HACKERS] Pluggable storage
Next
From: Julien Rouhaud
Date:
Subject: Re: [HACKERS] segfault in HEAD when too many nested functions call