Re: Patch: Platform-independent SSPI authentication support

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(at)chrullrich(dot)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
>