Re: Proposed Patch - LDAPS support for servers on port 636 w/o TLS - Mailing list pgsql-hackers

Thank you all for your comments.  I was unaware the ldaps: scheme was
not supposed to be used for LDAP+TLS encryption, but it makes sense now
that you mention it.

There's a nice discussion about how the folks working on mod_ldap for
Apache worked this out way back in 2005:


http://mail-archives.apache.org/mod_mbox/httpd-dev/200501.mbox/%3c6.2.0.14.2.20050104132551.054a1eb0@pop3.rowe-clan.net%3e

Anyway, I think we've distilled the issue down to how to best enable TLS
for ldap:// connections.

By my reckoning, that means we can have:
1) per-hba.conf entry configuration where the configuration canbe:
    a) of the ldap URL extension form mentioned by David    (!StartTLS).
    b) key=value type of param string as suggested by Magnus
    c) a specific URI scheme like ldap+tls:// like Tom    suggested.
    d) a new authentication type ldaptls
2) per-postgres server configuration which can be:    a) an old LDAPTLS environment variable ? needs research
    b) a server-wide GUC variable (along with TLSCERT    specifications?) as in the current patch

I'm open to other suggestions.

One other thing to keep in mind is how best to map database roles to
ldap Distinguished Name (dn) entries?

In other words, we need to take the user jimmy in
psql -U jimmy

and translate into an ldap authentication request for the distinguished
name that is entirely dependent on the site and ldap impl, example:
uid=jimmy,ou=people,dc=example,dc=com

I've racked my brain thinking of ways that this can fit cleanly in
hba.conf, but I haven't found anything I _really_ like (current patch 
and proposal 3 below are prob my favorites.) Any other
ideas/comments/suggestions?

# Current Functionality for reference - no tls control
host    dbname    all    127.0.0.0/32    ldap
"ldap://ldap.example.com[:port]/ignored;uid=;ou=people,dc=example,dc=com"

# Current Functionality in patch (w/ server wide TLS control in GUC var)
# GUC var causes all ldap entries to use same authentication. can be
# applied to service lookup as well
host    dbname    all    127.0.0.0/32    ldap "ldap://ldap.example.com[:port]/ou=people,dc=example,dc=com;uid="

# proposal 1 - RFC 2255 URI kind of yucky; scope, attributes, filter
# not actually used in simple authentication
host    dbname    all    127.0.0.0/32    ldap
"ldap://ldap.example.com[:port]/uid=%u,ou=people,dc=example,dc=com???!StartTLS"

# proposal 1b - still RFC 2255 compliant, but semantically weird.  no
# filter is actually used in simple authentication
host    dbname    all    127.0.0.0/32    ldap
"ldap://ldap.example.com[:port]/ou=people,dc=example,dc=com?one??(uid=%u)!StartTLS"

# proposal 2 - psuedo-URI scheme; hacky but easy
host    dbname    all    127.0.0.0/32    ldap "ldap+tls://ldap.example.com[:port]/ou=people,dc=example,dc=com;uid=;"

# proposal 3 - mod hba parsing, add new ldaptls auth type; reasonably
# easy and least invasive; 
host    dbname    all    127.0.0.0/32    ldaptls "ldap://ldap.example.com[:port]/ou=people,dc=example,dc=com;uid=;"

# proposal 4 - mod hba parsing
host    dbname    all    127.0.0.0/32    ldap "ldap://ldap.example.com[:port]/ou=people,dc=example,dc=com;uid=;"
StartTLS

# proposal 5 - Magnum's key = value like idea (i'm guessing here,
# Magnum.  If I misinterpret, please explain)
host    dbname    all    127.0.0.0/32    ldap
"ldap://ldap.example.com[:port]/ou=people,dc=example,dc=com;prefix=uid=;start_tls=1"

I have some radical ideas as well involving completely ripping out the
pg_hba.conf file but I'll leave that for another, more appropriate day.
:)

Thanks again for the feedback, and sorry for the verbosity.

-Steve (#postgresql rockpunk)