Обсуждение: Proposed Patch - LDAPS support for servers on port 636 w/o TLS
Hey Postgres Hackers,
this is my first time here, so... hi!
I've written a quick patch against the head branch (8.4DEV, but it also
works with 8.1.3 sources) to fix LDAP authentication support to
work with LDAPS servers that do not need start TLS. I'd be interested
to hear your opinions on this.
Quick overview:
The OpenLDAP recommended LDAPS configuration (as of OpenLDAP2.4?) is to have a regular (unencrypted) LDAP server
listeningonstandard port 389. Encryption will begin when the clientissues a STARTTLS request ala SMTPS.
Some older LDAP servers may not support TLS and instead have theSSL enabled ldap server listening on the ldaps port
(usually636).
While I agree it's probably not worth it to support older'unrecommended' setups, many organizations are slow on
theuptakeof recommended practices (mine is one of them :) ). Allowing PostgreSQL to work with these organization's
setupsoutof the box helps us pitch the db to organizations easier,especially those possibly overly paranoid about
security.
My solution was to create a boolean config variable calledldap_use_start_tls which the user can toggle whether or
notstarttls is necessary. The default is to use start tls and the recommended configuration. I also updated the
documentationandcleaned up the prefix/suffix/basedn interface so it's a bitmore intuitive to the user (i.e. - the
basednsetting isactually used, what they do are explained in the docs, etc.)Some people actually found that using an
authuri of:
ldaps://ldap.example.org/junk;cn=;,dc=example,dc=com
worked. I think a more intuitive form would be:
ldaps://ldap.example.org/dc=example,dc=com;cn=
though this can be debated.
If any of you are interested in this, feel free to check out the patch
located here:
http://rockpunk.org/ldaps-postgres_8.4DEV.patchhttp://rockpunk.org/ldaps-postgres_8.4DEV.patch.asc
Please note that this patch does not implement ldaps for Albe Laurenz'
code that allows config to pull from LDAP via pg_service.conf, though it
should be easy to do.
I have tested this patch on the following configurations:
Client OS: RHEL4
Database:Postgres 8.1.3 sourcesPostgres 8.4DEV (cvs HEAD branch as of Apr 24)
libldap client:OpenLDAP version 2.2.12 (latest for RHEL4 subscriptions)OpenLDAP version 2.3.39 (stable)
libldap server:OpenLDAP slapd version 2.2.x? on CentOS 4 or 5. (<-- no access)
Thanks a bunch,
-Steve (rockpunk @ #postgresql)
-- *------------------------*
// ste\/e || 0x158f7a45 //
*------------------------* live now. die later.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sat, Apr 26, 2008 at 11:02 AM, stephen layland wrote: > I've written a quick patch against the head branch (8.4DEV, but it also > works with 8.1.3 sources) to fix LDAP authentication support to > work with LDAPS servers that do not need start TLS. I'd be interested > to hear your opinions on this. > Hi Stephen, Your patch has been added to the queue at http://wiki.postgresql.org/wiki/CommitFest:May You can expect to receive review/feedback on your patch during the May commitfest, assuming nobody jumps on it before then. Cheers, BJ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: http://getfiregpg.org iD8DBQFIEocm5YBsbHkuyV0RAjgvAKCrXgRT6f4UtMcysXHTs3vdBcNf+gCeOQx4 4zw4SOwNCUVPJ4nHVPD7tcM= =4EXu -----END PGP SIGNATURE-----
stephen layland <steve@68k.org> writes:
> I've written a quick patch against the head branch (8.4DEV, but it also
> works with 8.1.3 sources) to fix LDAP authentication support to
> work with LDAPS servers that do not need start TLS. I'd be interested
> to hear your opinions on this.
Not being an LDAP user, I'm not very qualified to comment on the details
here, but ...
> My solution was to create a boolean config variable called
> ldap_use_start_tls which the user can toggle whether or not
> start tls is necessary.
... I really don't like using a GUC variable to determine the
interpretation of entries in pg_hba.conf. A configuration file exists
to set configuration, it shouldn't need help from a distance. Also,
doing it this way means that if several different LDAP servers are
referenced in different pg_hba.conf entries, they'd all have to have
the same encryption behavior.
I think a better idea is to embed the flag in the pg_hba.conf entry
itself. Perhaps something like "ldapso:" instead of "ldaps:" to
indicate "old" secure ldap protocol, or include another parameter
in the URL body.
regards, tom lane
Tom Lane wrote: > stephen layland <steve@68k.org> writes: > >> I've written a quick patch against the head branch (8.4DEV, but it also >> works with 8.1.3 sources) to fix LDAP authentication support to >> work with LDAPS servers that do not need start TLS. I'd be interested >> to hear your opinions on this. >> > > Not being an LDAP user, I'm not very qualified to comment on the details > here, but ... > > >> My solution was to create a boolean config variable called >> ldap_use_start_tls which the user can toggle whether or not >> start tls is necessary. >> > > ... I really don't like using a GUC variable to determine the > interpretation of entries in pg_hba.conf. A configuration file exists > to set configuration, it shouldn't need help from a distance. Also, > doing it this way means that if several different LDAP servers are > referenced in different pg_hba.conf entries, they'd all have to have > the same encryption behavior. > > I think a better idea is to embed the flag in the pg_hba.conf entry > itself. Perhaps something like "ldapso:" instead of "ldaps:" to > indicate "old" secure ldap protocol, or include another parameter > in the URL body. > With ldaps on port 636 STARTTLS should NEVER be issued, so the protocol identifier ldaps should be sufficient as "do not issue STARTTLS" flag. IMHO the current pg_hba.conf implementation doesn't follow the usual nomenclatura; ldap with TLS is still ldap. Using ldaps as indicator for ldap with tls over port 389 is misleading for anyone familiar with ldap. Regards, Andreas
Tom Lane wrote: > I think a better idea is to embed the flag in the pg_hba.conf entry > itself. Perhaps something like "ldapso:" instead of "ldaps:" to > indicate "old" secure ldap protocol, or include another parameter > in the URL body. FWIW, I'm working on a proposal to change how pg_hba.conf deals with the parameter field to make it easier to do things like this, by using a name/value pair setup instead. The LDAP url is one reason - it's hacky enough already *before* we add this kind of option to it... //Magnus
Andreas Pflug wrote: > With ldaps on port 636 STARTTLS should NEVER be issued, so the > protocol identifier ldaps should be sufficient as "do not issue > STARTTLS" flag. IMHO the current pg_hba.conf implementation doesn't > follow the usual nomenclatura; ldap with TLS is still ldap. Using > ldaps as indicator for ldap with tls over port 389 is misleading for > anyone familiar with ldap. I agree. ldaps:: should mean plain SSL without StartTLS. ldap:: should mean a plain text connection, unless some additional configuration directive enables StartTLS. There has been some discussion in the past about including (or not) this configuration state in the url : http://www.openldap.org/lists/openldap-devel/200202/msg00070.html
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)
Added to TODO: * Improve LDAP authentication configuration options http://archives.postgresql.org/pgsql-hackers/2008-04/msg01745.php --------------------------------------------------------------------------- steve layland wrote: -- Start of PGP signed section. > 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 can > be: > > 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) -- End of PGP section, PGP failed! -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. +