Hello all,
the attached patches provide support for the (Windows-only) SSPI
authentication method in the JDBC driver. They will need more testing; I
hope to find some volunteers here. Please note that these patches
support SSPI authentication by using the existing GSSAPI code, they do
_not_ require the underlying system to know anything about SSPI.
The patches are based on CVS HEAD. The resulting driver works on both
Windows 7 and Windows XP SP3 clients in a domain with a Windows 2008 DC,
accessing PostgreSQL 8.4.4 on a (different) Windows 2008 server. I have
not tested any other combination of clients and servers, if you have the
opportunity, please test it on your systems. It would be nice to find
out if non-Windows systems can log on to Windows servers configured for
SSPI if they are in the same Kerberos realm.
The first patch, "1-sspi-ConnectionFactoryImpl.patch", adds client-side
SSPI support in the simplest possible way: by acting as if it was the
same as GSSAPI. This works, probably because the Negotiate SSP that is
used by the server for SSPI authentication is clever enough to also
handle incoming GSSAPI tokens (without SPNEGO encapsulation). Although
this patch leads to successful authentication, it is therefore not a
complete solution, because it relies on the Negotiate SSP violating its
own protocol.
I have only tested the combination of clients and server I described
above; if you have the opportunity, please test it on your systems.
The second patch, "2-sspi-MakeGSS.patch", improves on the first one by
adding the OID for the SPNEGO mechanism to the authenticator. This works
only on Sun Java 1.6 and later; SPNEGO support is not available in
earlier releases. With this change, the SPNEGO negotiation is actually
performed on the wire. In my environment, this works even with
"sun.security.spnego.msinterop=false".
Even though this change resulted in perfect authentication in my
environment, I keep thinking, "it was too easy". If you agree, please
let me know what I failed to consider.
--
Christian