Re: LDAP where DN does not include UID attribute - Mailing list pgsql-hackers

From Robert Fleming
Subject Re: LDAP where DN does not include UID attribute
Date
Msg-id 4c0112730909171824m261e7ed5nfdb884b4b264bd2d@mail.gmail.com
Whole thread Raw
In response to Re: LDAP where DN does not include UID attribute  (Magnus Hagander <magnus@hagander.net>)
Responses Re: LDAP where DN does not include UID attribute
Re: LDAP where DN does not include UID attribute
List pgsql-hackers
On Thu, Sep 17, 2009 at 11:15 AM, Magnus Hagander <magnus@hagander.net> wrote:
On Thu, Sep 17, 2009 at 18:02, Robert Fleming <fleminra@gmail.com> wrote:
> Following a discussion on the pgsql-admin list
> <http://archives.postgresql.org/pgsql-admin/2009-09/msg00075.php>, I have
> created a patch to (optionally) allow PostgreSQL to do a LDAP search to
> determine the user's DN (as is done in Apache, MediaWiki, Bugzilla, et al.)
> instead of building the DN from a prefix and suffix.
> This is necessary for schemas where the login attribute is not in the DN,
> such as is described here
> <http://www.ldapman.org/articles/intro_to_ldap.html#individual> (look for
> "name-based").  This patch is against PostgreSQL 8.4.0 from Debian
> Lenny-backports.  If this would be a welcome addition, I can port it forward
> to the latest from postgresql.org.
> Thanks in advance for your feedback.

This sounds like a very useful feature, and one that I can then remove
from my personal TODO list without having to do much work :-)

A couple of comments:

First of all, please read up on the PostgreSQL coding style, or at
least look at the code around yours. This doesn't look anything like
our standards.

Sorry, the 8.1 manual said all contributions go through pgindent so I didn't spend too much time on that.  I see that the 8.4 manual clarifies that pgindent won't get run till release time.  In any case, I've re-formatted the patch using the Emacs settings from the 8.1 manual (why are they gone from the 8.4 manual)?  It seems like most of the rest of the Coding Conventions have to do with error reporting.  Do please let me know if there's something else I can do.

Second, this appears to require an anonymous bind to the directory,
which is something we should not encourage people to enable on their
LDAP servers. I think we need to also take parameters with a DN and a
password to bind with in order to do the search, and then re-bind as
the user when found.

The new patch implements the initial bind using new configuration parameters "ldapbinddn" and "ldapbindpasswd".  I've also added a "ldapsearchattribute" just to be complete.

Robert
Attachment

pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: generic copy options
Next
From:
Date:
Subject: Re: PGCluster-II Progress