Re: JAVA Support - Mailing list pgsql-hackers

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.
Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu