Обсуждение: LDAP where DN does not include UID attribute

Hello,

I have an LDAP server where the DN looks like:

cn=robert fleming,cn=users,dc=abc,dc=example,dc=com

But I would like to authenticate to PostgreSQL using the "uid" LDAP attribute, which you may notice is *not* in the DN.  It seems to me that PostgreSQL's LDAP support does not allow this.

Other software products I've seen support this by doing an LDAP query *first*, and then fetching/building the DN from the search result, and then using that DN to do the bind.  Looking at the PostgreSQL source code, it seems like PostgreSQL expects to be able to do a bind without doing a search first.

==Examples for reference==
===MediaWiki===
====LocalSettings.php====
$wgLDAPServerNames = array("example"=>"ldap.example.com");
$wgLDAPSearchAttributes = array("example"=>"uid");
$wgLDAPBaseDNs = array("loral"=>"cn=users,dc=abc,dc=example,dc=com");

====LdapAuthentication.php====
see <http://svn.wikimedia.org/viewvc/mediawiki/trunk/extensions/LdapAuthentication/LdapAuthentication.php?view=markup>
Look for "function getUserDN"

===Bugzilla===
====params====
%param = (
           'LDAPBaseDN' => 'cn=users,dc=ssd,dc=loral,dc=com',
           'LDAPbinddn' => '',
           'LDAPfilter' => '',
           'LDAPmailattribute' => 'mail',
           'LDAPserver' => 'ldap.example.com',
           'LDAPstarttls' => 0,
           'LDAPuidattribute' => 'uid',
...

====LDAP.pm====
see <http://mxr.mozilla.org/bugzilla/source/Bugzilla/Auth/Verify/LDAP.pm>
Look at about line 64 to see that they do a LDAP search before the LDAP bind.

In contrast, PostgreSQL's backend/libpq/auth.c does ldap_simple_bind_s() but never does a LDAP search.

Thanks,
Robert

Robert Fleming <fleminra@gmail.com> writes:
> But I would like to authenticate to PostgreSQL using the "uid" LDAP
> attribute,

What value does that have that would justify doubling the time needed
to authenticate?  (I presume two LDAP requests will take about twice
as long as one...)

            regards, tom lane

On Mon, Sep 14, 2009 at 4:23 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

That's just the way the company LDAP is setup -- it's out of my control unfortunately.

Our schema used to have the uid in the DN, and I always wrote our enterprise software to just do the bind without a search.  When the LDAP schema changed, my reaction was the same as yours, but when I saw that Bugzilla, MediaWiki, etc. accommodate it without flinching, I figured it wasn't too uncommon, so I changed my own software.  Other software that supports it: Tiki wiki, Apache's mod_authnz_ldap, ejabberd.  I think I had to tweak some Perl for jabberd <jabberd.org> to handle it.

It might be twice as slow, but if PostgreSQL were smart or configurable enough, it could skip the search when not necessary.  So performance needn't be impacted.

Robert

On Mon, Sep 14, 2009 at 5:47 PM, Robert Fleming <fleminra@gmail.com> wrote:
> On Mon, Sep 14, 2009 at 4:23 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>
>> Robert Fleming <fleminra@gmail.com> writes:
>> > But I would like to authenticate to PostgreSQL using the "uid" LDAP
>> > attribute,
>>
>> What value does that have that would justify doubling the time needed
>> to authenticate?  (I presume two LDAP requests will take about twice
>> as long as one...)
>
> That's just the way the company LDAP is setup -- it's out of my control
> unfortunately.
>
> Our schema used to have the uid in the DN, and I always wrote our enterprise
> software to just do the bind without a search.  When the LDAP schema
> changed, my reaction was the same as yours, but when I saw that Bugzilla,
> MediaWiki, etc. accommodate it without flinching, I figured it wasn't too
> uncommon, so I changed my own software.  Other software that supports it:
> Tiki wiki, Apache's mod_authnz_ldap, ejabberd.  I think I had to tweak some
> Perl for jabberd <jabberd.org> to handle it.
>
> It might be twice as slow, but if PostgreSQL were smart or configurable
> enough, it could skip the search when not necessary.  So performance needn't
> be impacted.

On a large ldap schema it's WAY more than twice as slow.  A Search is
about 10 to 20 times slower on most ldap servers. I've seen machines
handling 1,000 or more auths per second slow to a crawl due to this
type of change.

On Tue, Sep 15, 2009 at 12:27 AM, Robert Fleming
<fleming@cs.washington.edu> wrote:
> On Mon, Sep 14, 2009 at 4:56 PM, Scott Marlowe <scott.marlowe@gmail.com>
> wrote:
>>
>> On Mon, Sep 14, 2009 at 5:47 PM, Robert Fleming <fleminra@gmail.com>
>> wrote:
>> > On Mon, Sep 14, 2009 at 4:23 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> >>
>> >> Robert Fleming <fleminra@gmail.com> writes:
>> >> > But I would like to authenticate to PostgreSQL using the "uid" LDAP
>> >> > attribute,
>> >>
>> >> What value does that have that would justify doubling the time needed
>> >> to authenticate?  (I presume two LDAP requests will take about twice
>> >> as long as one...)
>> >
>> > That's just the way the company LDAP is setup -- it's out of my control
>> > unfortunately.
>> >
>> > Our schema used to have the uid in the DN, and I always wrote our
>> > enterprise
>> > software to just do the bind without a search.  When the LDAP schema
>> > changed, my reaction was the same as yours, but when I saw that
>> > Bugzilla,
>> > MediaWiki, etc. accommodate it without flinching, I figured it wasn't
>> > too
>> > uncommon, so I changed my own software.  Other software that supports
>> > it:
>> > Tiki wiki, Apache's mod_authnz_ldap, ejabberd.  I think I had to tweak
>> > some
>> > Perl for jabberd <jabberd.org> to handle it.
>> >
>> > It might be twice as slow, but if PostgreSQL were smart or configurable
>> > enough, it could skip the search when not necessary.  So performance
>> > needn't
>> > be impacted.
>>
>> On a large ldap schema it's WAY more than twice as slow.  A Search is
>> about 10 to 20 times slower on most ldap servers. I've seen machines
>> handling 1,000 or more auths per second slow to a crawl due to this
>> type of change.
>
> I'll come up with a patch to support search+bind a la Apache, etc., and
> retain the existing logic as an optimized sub-case.  I think the cost of an
> additional conditional branch instruction will be negligible w.r.t. the LDAP
> bind.  I suppose this should go to the development list.
> I mainly just wanted to confirm with this list that this is a scenario that
> is not currently covered by PostgreSQL.

Yeah, it's really a question of scalability.  If a app is constantly
authenticating then it could be a problem.  The problem stems from
authentication being a bolt on for LDAP, instead of a primary
function, like kerberos.  If it was just username and password, check
out a token, you'd have it easy(ier?), right?

First, as I mentioned, I'm not proposing to impose a "search" operation on all users.  It could be a configuration option, or it might be possible for PostgreSQL to be smart enough to know that it doesn't need to do a search.  FWIW, a quick look at the Apache source code makes me think that they are not concerned with this overhead.

Second (only for the sake of argument), I could imagine designing an LDAP server for which this particular search operation is no slower than a bind.  (This I say without the benefit of having implemented or administered any LDAP server.)

I will probably make the mod myself because of course I won't see this feature in a release in the near future, in any case, and it's an easy change.  My goal of writing to this list was mainly to confirm that PostgreSQL is currently *not* able to handle this scenario.  Based on the conversation so far I take it that that is a correct assessment?

Thanks,
Robert