Re: BUG #9337: SSPI/GSSAPI with mismatched user names

* Brian Crowell (brian(at)fluggo(dot)com) wrote:
> On Tue, Feb 25, 2014 at 11:07 AM, Stephen Frost <sfrost(at)snowman(dot)net> wrote:
> > On the other hand, Magnus removing the krb5 auth method also removed
> > krb_server_hostname.. I'll ask him about that because we should
> > probably make that available under 'gss' or we may end up leaving some
> > of our users out in the cold when 9.4 comes out and that'd be quite
> > unfortuante.
>
> I'd be interested in why the principal needs to be specified ahead of
> time, since it arrives in the ticket. Is it a limitation of the
> Kerberos APIs? Or maybe it's to prevent using a different key from the
> key file?

Yeah, I'm pretty sure you have to set up the server-side stuff before
you can actually pass control to GSSAPI (really, the whole thing
is insane because GSSAPI actually wants to control the socket on both
ends to do whatever communication it needs to with it, so that's why
you set everything up, pass control of the socket to the GSSAPI library
on both sides, and then check what answer you get back from it at the
end). Note that the princ we're talking about here is the *server-side*
princ, not the client-side one.

> > If we decide to allow an option where we use the 'default cred' in
> > GSSAPI to also determine the PG username we are authenticating to, we'll
> > want to think about how we support that in libpq and psql and consider
> > what to do about the limitations of not being able to specify different
> > krb_server_hostname depending on the user which is attempting to
> > authenicate.
>
> I figured this would be an optional extension, something you could
> request in the initial packet. You would explicitly ask for it using
> some special invocation of psql, like "psql -K" the way ssh does. As
> such, if there are going to be limitations, you could just choose to
> authenticate the normal way.

That sounds reasonable to me.

Thanks!

Stephen