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


On Sun, Jul 16, 2017 at 1:08 AM, Thomas Munro <thomas.munro@enterprisedb.com> wrote:
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.

Agreed, but I'm not sure it's a good style to follow (and yes, I think I may be the original author of it..). I'd rank option 3 over option 1.
 

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

Yeah, that's exactly what I'm wondering about it :)

 

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?



+1 for some input from people who directly use it in larger LDAP environments. If we're going to change how it works, let's make it right this time! 

--

pgsql-hackers by date:

Previous
From: Dean Rasheed
Date:
Subject: Re: [HACKERS] Multi column range partition table
Next
From: Robert Haas
Date:
Subject: Re: [HACKERS] Something for the TODO list: deprecating abstime and friends