Re: SSPI authentication

Stephen Frost wrote:
> * Magnus Hagander (magnus(at)hagander(dot)net) wrote:
>>> The way this is handled in a number of other applications (putty being
>>> the one that comes to mind easily) is that two DLLs are built- one for
>>> SSPI and one for GSSAPI and you can easily switch between them on the
>>> client. That'd work fine for us.
>> Well, that you can do - you just need one libpq with sspi and one with
>> gssapi.
>
> If both are made available then I think that'd work fine for us. I'm
> concerned that the windows builds wouldn't include a version of libpq w/
> GSSAPI...

The default build wouldn't. The binary build wouldn't. If you by GSSAPI
mean MIT linking - SSPI does GSSAPI *authentication* just fine.

One reason is that bringing in and configuring the MIT libraries is a
significant overhead.

Nothing would prevent you from building your own DLL with Kerberos linking.

> If I was confident that we could easily build it ourselves
> then I wouldn't care as much but, since I've never had to build libpq on
> Windows before, I'm not sure what effort is involved or what tools are
> required. I'm also not thrilled by the prospect. :)

It's not hard, at least if you use MSVC to build it. It's harder with
MingW, but far from impossible.

>>> I don't like the idea of having to rebuild things under Windows,
>>> honestly.. Not that I like to build anything these days... If it's not
>>> enabled by default in some way I expect that it'd get 'forgotten'.
>> Ok, so looking at it from the other direction, say we wanted to support
>> both. Then we need to invent a new way for the client to tell libpq
>> which one to use. I think that's sensible if it's a common thing, but I
>> still see it as a *very* narrow use-case that needs both in the same DLL.
>> Or do you have a better idea on how to solve that?
>
> Supporting both is actually exactly what Mozilla does... Check out the
> 'network.auth.use-sspi' flag in about:config. It's also what KfW does
> "Include Windows LSA cache" and "Import windows credentials", which has
> the interesting option of "only when principals match". I'm not sure if
> there's a sane way to test at run-time if KfW exists but its existance
> could be used as a factor.

Not easily - it can certainly be done, but it requires a significant
change in both krb5 and gssapi auth codepaths.

Also, the fact that kfw exists in no way means that it's configured and
set up, so in itself that's not a good enough way to decide. I don't see
any way of doing that automatically.

> I have to admit that this does kind of make
> me wish a bit for a 'libpq config file' even though I'm generally against
> such things. Having the same easy switch as we do w/ Mozilla would be
> really nice.

So what we'd need in that case is a new libpq connectionstring
parameter. Which can be done, but it'd require that all frontends that
use libpq add support for it - such as pgadmin. I'm not sure if the ODBC
driver will support arbitrary arguments, otherwise that one needs it too.

As I'm sure you can tell, I'm far from convinced this is a good idea ;-)
Anybody else want to comment on this?

//Magnus