On Sep 28, 2006, at 12:42 PM, Magnus Hagander wrote:

2) If I were willing to add a GSSAPI or SASL layer as an
alternative to the bare Krb 5 support would anyone be willing
to help with the supporting mods to the pg_hba.conf parsing,
and configure?

Sure, I can help out with that. I've done a bunch of work on the current
kerberos stuff (tohugh I'm by no means the author) in order to make it
work on win32, so I have a little bit of a clue around that code ATM.

As for the other part - will core accept this - I can't answer that. I
do beleive that there is a point to it, given that Java will then
support it natively, but I'm not core. I'm unsure if there is a clear
view on the merits of adding more authentication options..

From the lack of traffic on this list I gather that the core developers no longer hang out here. I've been gone for a few years.

For the record here's the arguments:

SASL is a "standards track RFC" (I saw those snide comments in the record, Mr. Lane ;-) which allows you to plug in authentication mechanisms, much like PAM allows you to plug in password checkers. It is well adopted, since it forms the basis of most email protocols' authentication, as well as LDAP and Jabber.

SASL provides a unified way for code to support all the authentication options you're likely to want.

a) In the absence of OS-provided SASL libraries a simple password- checking mechanism could be implemented as a wire-compatible fallback with less code than the framework would take. (I won't write this, but you could probably steal code from jabberd.)

b) SASL includes simple password checking mechanisms. In principle we could use these to check the local postgres passwords. Not sure how much customization that would require.

c) If you are using SSL/TLS for client/server connections (or it's a local on-machine connection) you can use the SASL_EXTERNAL mechanism to pick up the identity from the connection, without imposing extra overhead.

d) SASL includes enterprise-class authentication support, such as GSSAPI (and Kerberos via GSSAPI). If an enterprise has some unique authentication infrastructure it can be implemented as a SASL (or GSSAPI) plug-in without the need to customize PostgreSQL.

e) After the initial connection, SASL can be configured to run the connection fully encrypted, integrity protected, or unprotected.

f) SASL support is available in current Java as well as C. SASL libraries are included (or at least loadable) on MacOS, Solaris 10+, and Linux. (I don't do windows, so I can't say there.) While it has a reputation for complexity, that complexity is in building the libraries, not in using them.

It can be used to provide most (all?) of the functionality now provided by the assortment of existing mechanisms. If provided as an alternative, it could eventually allow decommissioning of a lot of the other mechanisms. If the number of existing mechanisms is an issue, then this could be a big long-term win.

I'll assume the ball is in my court now, unless someone wants to claim I should just do GSSAPI and not bother with the higher level. ------------------------------------------------------------------------ ----
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

Reply via email to