Re: Patch: Platform-independent SSPI authentication support
От | Dave Cramer |
---|---|
Тема | Re: Patch: Platform-independent SSPI authentication support |
Дата | |
Msg-id | CADK3HHLvC41H8qZh5TzewGdqh9WF1RJrsMj_TKBsZORN-ZcWTw@mail.gmail.com обсуждение исходный текст |
Ответ на | Patch: Platform-independent SSPI authentication support (Christian Ullrich <chris@chrullrich.net>) |
Список | pgsql-jdbc |
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 >
В списке pgsql-jdbc по дате отправления:
Следующее
От: Роман ЛитовченкоДата:
Сообщение: Fwd: plpgsql function, comment with single quote, braces