Re: Future of krb5 authentication

Magnus Hagander wrote:
> Heikki Linnakangas wrote:
>> Stephen Frost wrote:
>>> Honestly, for now I'm happy w/ it being a connectionstring option. It
>>> seems the most appropriate place for it to go. That does mean that
>>> applications may need to be modified to support gssapi (where they might
>>> not have to be for sspi since it's the default), but since we're going
>>> to keep krb5 support around for a bit there's time for those
>>> applications to catch up without breaking things explicitly for people
>>> migrating to 8.3.
>> Isn't it possible to open the socket, try GSSAPI handshaking with
>> protocol, and fall back to krb5 protocol if that fails? If that's not
>> possible, how about handling it like we handle postgres protocol 3 vs 2?
>> Connect using GSSAPI first, and if that fails, retry with krb5.
>
> The issue is *not* about GSSAPI vs krb5. It's with GSSAPI vs SSPI.
>
> The wire protocol is the same for them. It's a matter of which *client
> library* should be used to produce the packets that go over the network.

Uh, this is really confusing. Let's see if I got this right. So we're
talking about two orthogonal changes here:

1. Wire protocol. In 8.2 and below, we used the krb5 protocol. 8.3
server and libpq will use the GSSAPI wire protocol by default, with
support for krb5 protocol when speaking with older versions.

2. In 8.2 and below, we used the GSSAPI library on all platforms. 8.3
adds support for Microsoft's SSPI interface on Windows.

On Windows, why would you need GSSAPI, if SSPI comes with the operation
system? What's the difference between the libraries? Can you try SSPI
first, and fall back to GSSAPI?

Can you do <= 8.2 style krb5 authentication with the SSPI library?

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com