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 OpenLDAP
2.4?) is to have a regular (unencrypted) LDAP server listening
on standard port 389. Encryption will begin when the client
issues a STARTTLS request ala SMTPS.

Some older LDAP servers may not support TLS and instead have the
SSL enabled ldap server listening on the ldaps port (usually
636).

While I agree it's probably not worth it to support older
'unrecommended' setups, many organizations are slow on the
uptake of recommended practices (mine is one of them ).
Allowing PostgreSQL to work with these organization's setups out
of 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 called
ldap_use_start_tls which the user can toggle whether or not
start tls is necessary. The default is to use start tls and
the recommended configuration. I also updated the documentation
and cleaned up the prefix/suffix/basedn interface so it's a bit
more intuitive to the user (i.e. - the basedn setting is
actually used, what they do are explained in the docs, etc.)
Some people actually found that using an auth uri 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.patch
http://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 sources
Postgres 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 SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFIEn8wIBlLQBWPekURAiXSAJ9nAQ0nh2jJGBisAG8jK/Bmc4zgmACgmYFR
XakbU2u+7W7rAXv32fMFMNc=
=y3/C
-----END PGP SIGNATURE-----

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

iD8DBQFIEocm5YBsbHkuyV0RAjgvAKCrXgRT6f4UtMcysXHTs3 vdBcNf+gCeOQx4
4zw4SOwNCUVPJ4nHVPD7tcM=
=4EXu
-----END PGP SIGNATURE-----

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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/openld.../msg00070.html



--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/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_...we-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[ort]/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[ort]/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[ort]/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[ort]/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[ort]/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[ort]/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[ort]/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[ort]/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)

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFIH9ZbIBlLQBWPekURAijtAJ93Vk6lVkeBl7dTmSGvXx Cpe5m9aACdFBng
TCB+D4+2imkgl982mhNOGu0=
=x8BK
-----END PGP SIGNATURE-----

Added to TODO:

* Improve LDAP authentication configuration options

http://archives.postgresql.org/pgsql...4/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_...we-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[ort]/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[ort]/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[ort]/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[ort]/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[ort]/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[ort]/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[ort]/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[ort]/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. +

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers