Обсуждение: Patch: Platform-independent SSPI authentication support

[A year has gone by since I last posted this message with no
  response (maybe because it didn't show up on the list either), so
  I'm trying again.]

The attached patch provides platform-independent support for the SSPI
authentication method (that is only supported by servers running on
Windows) in the JDBC driver. Please note that this patch supports SSPI
authentication by using the existing GSSAPI code, it does _not_
require the underlying system to know anything about SSPI.

I should also point out that GSSAPI support has been removed from the
PostgreSQL binary installers for Windows in version 9.0, so there is
currently no authentication method available in these builds that
supports passwordless authentication via the JDBC driver.

The patch applies against REL9_1_STABLE, as well as CVS trunk. I have
not tested it in a while, but last year, the resulting driver worked
on both Windows 7 and Windows XP SP3 clients in a domain with a
Windows 2008 DC, accessing PostgreSQL 8.4.4 and 9.0.2 on a Windows
2008 server, and there has been very little change in the affected
code. The equivalent change to libpq, which has been released in
9.1.2, worked in all environments I tested in. [1]

The patch does two things:

- It adds client-side SSPI support in the simplest possible way: by
   acting as if it was the same as GSSAPI. This works 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). This is the documented behavior of the Negotiate
   SSP, it is not a compatilibity quirk.

- It improves on that 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, authentication succeeds even with
   "sun.security.spnego.msinterop=false", if that even has any effect.

[1]
<http://archives.postgresql.org/message-id/4D3C42F3.4080503@chrullrich.net>

Christian,

You mentioned that this works only on java 6. Will it compile on java 1.4 ?
Dave Cramer

dave.cramer(at)credativ(dot)ca
http://www.credativ.ca



On Tue, Jan 10, 2012 at 8:07 AM, Christian Ullrich <chris@chrullrich.net> wrote:
> [A year has gone by since I last posted this message with no
>  response (maybe because it didn't show up on the list either), so
>  I'm trying again.]
>
> The attached patch provides platform-independent support for the SSPI
> authentication method (that is only supported by servers running on Windows)
> in the JDBC driver. Please note that this patch supports SSPI authentication
> by using the existing GSSAPI code, it does _not_ require the underlying
> system to know anything about SSPI.
>
> I should also point out that GSSAPI support has been removed from the
> PostgreSQL binary installers for Windows in version 9.0, so there is
> currently no authentication method available in these builds that supports
> passwordless authentication via the JDBC driver.
>
> The patch applies against REL9_1_STABLE, as well as CVS trunk. I have not
> tested it in a while, but last year, the resulting driver worked on both
> Windows 7 and Windows XP SP3 clients in a domain with a Windows 2008 DC,
> accessing PostgreSQL 8.4.4 and 9.0.2 on a Windows 2008 server, and there has
> been very little change in the affected code. The equivalent change to
> libpq, which has been released in 9.1.2, worked in all environments I tested
> in. [1]
>
> The patch does two things:
>
> - It adds client-side SSPI support in the simplest possible way: by
>  acting as if it was the same as GSSAPI. This works 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). This is the documented behavior of the Negotiate
>  SSP, it is not a compatilibity quirk.
>
> - It improves on that 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, authentication succeeds even with
>  "sun.security.spnego.msinterop=false", if that even has any effect.
>
> [1]
> <http://archives.postgresql.org/message-id/4D3C42F3.4080503@chrullrich.net>
>
>
> --
> Sent via pgsql-jdbc mailing list (pgsql-jdbc@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-jdbc
>

* Dave Cramer wrote:

> You mentioned that this works only on java 6. Will it compile on java 1.4 ?

I believe so (though I cannot claim to know for sure). My additions
(which consist of one whole line of code) do not reference any classes
that are not already used in the surrounding driver.

Whether the modified MakeGSS will run on Java 1.4, I'm not so sure,
because support for the SPNEGO mechanism (1.3.6.1.5.5.2) was only
added in Java 6. If that is a problem, the change to MakeGSS can be
left out without losing functionality or introducing interoperability
issues.

--
Christian

Christian,

Thanks for this patch I've committed it.

Dave Cramer

dave.cramer(at)credativ(dot)ca
http://www.credativ.ca



On Mon, Jan 16, 2012 at 10:32 AM, Christian Ullrich
<chris@chrullrich.net> wrote:
> * Christian Ullrich wrote:
>
>> * Dave Cramer wrote:
>>
>>> What about just testing the version , and including that based on
>>> version ?
>>
>>
>> Er, yes. Why not? Only I'd prefer to test for the presence of the
>> feature, rather than a specific version -- after all, there are
>> rumored to be Java implementations from people other than Sun^WOracle.
>
>
> OK, here's a new version, split into two patches this time. The resulting
> driver compiles with Java 1.4 and works on Java 6, but it does not
> authenticate when running on 1.4. [1]
>
>
> The first patch, 1-sspi-enable.patch, is the same change to
> ConnectionFactoryImpl from earlier. It simply replaces the "SSPI
> unsupported" error message with an attempt to perform SSPI using the
> existing GSSAPI code.
>
> This patch does not introduce any new failure conditions. It does, however,
> change the behavior in situations where SSPI authentication does not
> succeed. Without the patch, the user will get the "SSPI unsupported" error,
> with it, the error will be "Authentication failed", or any of the
> innumerable GSS-API errors that may happen.
>
>
> The second patch, 2-sspi-spnego.patch, additionally allows the user to
> enable SPNEGO instead of plain Kerberos V5 as the authentication mechanism.
>
> I have not been able to find a way to detect whether the _server_ supports
> SPNEGO [2], so it will only be used if the client's Java does and if the
> user explicitly requests it through a connection property (useSpnego).
>
> Both MIT (since 1.5, June 2006) and Heimdal (since 0.8, April 2007) support
> SPNEGO, as, obviously, does Windows.
>
> Like its previous versions, the second patch is not required for the first
> to work. It is simply an additional feature that may be useful in specific
> situations.
>
> Another caveat: I think that with SPNEGO enabled, the negotiation may result
> in selecting NTLM. I have no idea a) how to verify that, or b) what the
> result will be if it happens.
>
>
> [1] I think this is an interoperability problem in my environment. Java 1.4
> only supports DES encryption; neither my KDC nor my PostgreSQL server are
> all that happy with DES anymore. The error message is "enctype X not
> supported" with X=1 (DES-CBC-CRC) and 3 (DES-CBC-MD5). I _think_ I told the
> KDC to issue such tickets, and the server to accept them, but I'm not
> certain.
>
> [2] At least not without starting the authentication exchange with SPNEGO
> first and then retrying from the start with plain Kerberos if the first
> attempt fails. That would both increase connection time measurably and cause
> one failed authentication attempt for every successful one. I suspect that
> few users would appreciate that, so I left it out. If they still have
> trouble, it's because they asked for it (by enabling SPNEGO).
>
> --
> Christian
>