Re: JAVA Support

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(dot)B(dot)Hotz(at)jpl(dot)nasa(dot)gov, or hbhotz(at)oxy(dot)edu