Thread: SSPI authentication
A quick status update on the SSPI authentication part of the GSSAPI project. I have libpq SSPI working now, with a few hardcoded things still in there to be fixed. But it means that I can connect to a linux server using kerberos/GSSAPI *without* the need to set up MIR Kerberos libraries and settings on the client. This is great :-) The code is fairly trivial. I've set it up as a different way of doing GSSAPI authentication. This means that if you can't have both SSPI and MIT KRB GSSAPI in the same installation. I don't see a problem with this - 99.9% of windows users will just want the SSPI version anyway. But I figured I'd throw it out here to see if there are any objections to this? I'd like to make this enabled by default on Win32, since all supported windows platforms have support for it. Then we can add a configure option to turn it *off* if we want to. Comments? Do we even need such an option? Right now, the SSPI path is hardcoded to just support Kerberos. Once we have both client and server with SSPI support I see no reason to keep this restriction. Anybody against that? (Not saying that'll happen for 8.3, because it certainly needs a bunch of extra testing, but eventually) //Magnus
* Magnus Hagander (magnus@hagander.net) wrote:
> I've set it up as a different way of doing GSSAPI authentication. This
> means that if you can't have both SSPI and MIT KRB GSSAPI in the same
> installation. I don't see a problem with this - 99.9% of windows users
> will just want the SSPI version anyway. But I figured I'd throw it out
> here to see if there are any objections to this?
I'm not quite sure if that would affect what we do but it sounds like it
might. The main thing we use on the clients wrt Postgres is the ODBC
driver but I've used psql once or twice and have been trying to get
people to learn it.
We've got SSPI which is used for the Windows domain (and only the windows
resources) and then MIT Krb5 GSSAPI for the Unix resources. While
cross-realm is a nice idea it's less than easy to get going, especially
with even a half-way secure key (I'm not exactly a big fan of
arc/rc4...).
So, we have seperate key caches on each client that needs access to both
resources and that allows us to manage things much more easily and
seperately from the corporate folks running the Windows domain.
Additionally, it seems likely to me that there will be cases when people
running Windows don't *want* to set up an Active Directory for their
Windows machines but want to use Kerberos to auth to certain resources
(perhaps a campus environment where student systems aren't joined to an
AD domain?). Would that be possible with this? I havn't done much w/
SSPI so I'm not sure how deeply that's tied into things like that.
Thanks,
Stephen
Stephen Frost wrote: > * Magnus Hagander (magnus@hagander.net) wrote: >> I've set it up as a different way of doing GSSAPI authentication. This >> means that if you can't have both SSPI and MIT KRB GSSAPI in the same >> installation. I don't see a problem with this - 99.9% of windows users >> will just want the SSPI version anyway. But I figured I'd throw it out >> here to see if there are any objections to this? > > I'm not quite sure if that would affect what we do but it sounds like it > might. The main thing we use on the clients wrt Postgres is the ODBC > driver but I've used psql once or twice and have been trying to get > people to learn it. ODBC driver should work with it - I don't know exactly how they plug into libpqs auth, but IIRC they do some stuff to make that work. Note that I'm only talking about being mutually exclusiv ewith MIT KRB GSSAPI, not with MIT KRB in "krb5" mode. Though I very much want to deprecate the "native kerberos" auth in favor of GSSAPI as soon as possible for several reasons, so I'd suggest you don't use that once you go to 8.3 ;-) > We've got SSPI which is used for the Windows domain (and only the windows > resources) and then MIT Krb5 GSSAPI for the Unix resources. While > cross-realm is a nice idea it's less than easy to get going, especially > with even a half-way secure key (I'm not exactly a big fan of > arc/rc4...). I have my Unix machines in the Active Directory, so there's no cross realm. It works fine. And if you don't trust the key, put it over SSL? ;-) If you use SSL, GSSAPI packets actually go through the SSL tunnel, unlike krb5 auth. > Additionally, it seems likely to me that there will be cases when people > running Windows don't *want* to set up an Active Directory for their > Windows machines but want to use Kerberos to auth to certain resources > (perhaps a campus environment where student systems aren't joined to an > AD domain?). Would that be possible with this? I havn't done much w/ > SSPI so I'm not sure how deeply that's tied into things like that. Yes, there's still support for doing GSSAPI with MIT KRB5. It's just that you have to use it *instead* of SSPI. So a rebuild is necessary. But - IIRC, you can just join your windows machine to your unix kerberos realm and be done with it - SSPI APIs should work fine in that case. //Magnus
* Magnus Hagander (magnus@hagander.net) wrote:
> Stephen Frost wrote:
> > I'm not quite sure if that would affect what we do but it sounds like it
> > might. The main thing we use on the clients wrt Postgres is the ODBC
> > driver but I've used psql once or twice and have been trying to get
> > people to learn it.
>
> ODBC driver should work with it - I don't know exactly how they plug
> into libpqs auth, but IIRC they do some stuff to make that work.
I wouldn't be so sure... I'm not exactly a fan of how ODBC does that
anyway, it essentially uses libpq for the auth, *sometimes*, and then
hijacks the connection away.
> Note that I'm only talking about being mutually exclusiv ewith MIT KRB
> GSSAPI, not with MIT KRB in "krb5" mode. Though I very much want to
> deprecate the "native kerberos" auth in favor of GSSAPI as soon as
> possible for several reasons, so I'd suggest you don't use that once you
> go to 8.3 ;-)
The KfW stuff from MIT provides both GSSAPI and 'native' kerberos, I
believe, and most things use the GSSAPI side of it, actually.
> > We've got SSPI which is used for the Windows domain (and only the windows
> > resources) and then MIT Krb5 GSSAPI for the Unix resources. While
> > cross-realm is a nice idea it's less than easy to get going, especially
> > with even a half-way secure key (I'm not exactly a big fan of
> > arc/rc4...).
>
> I have my Unix machines in the Active Directory, so there's no cross
> realm. It works fine.
Yeah, that requires quite a bit more involvement between us and the
corporate folks, and means that we're dependent on them to do things
before we can do things. That tends to end badly.
> And if you don't trust the key, put it over SSL? ;-) If you use SSL,
> GSSAPI packets actually go through the SSL tunnel, unlike krb5 auth.
Uhh, the client and the KDC don't generally use SSL to talk to each
other, last I checked, and the problem is with the cross-realm key (you
know, the one that you could use to fake anyone from the trusted realm)
having to be least-common-denominator between Windows and Unix since it
has to exist in both KDCs. That wouldn't be too much trouble if that
least-common-denominator was AES256 but at the moment it's not.
> > Additionally, it seems likely to me that there will be cases when people
> > running Windows don't *want* to set up an Active Directory for their
> > Windows machines but want to use Kerberos to auth to certain resources
> > (perhaps a campus environment where student systems aren't joined to an
> > AD domain?). Would that be possible with this? I havn't done much w/
> > SSPI so I'm not sure how deeply that's tied into things like that.
>
> Yes, there's still support for doing GSSAPI with MIT KRB5. It's just
> that you have to use it *instead* of SSPI. So a rebuild is necessary.
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.
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'.
> But - IIRC, you can just join your windows machine to your unix kerberos
> realm and be done with it - SSPI APIs should work fine in that case.
I don't think that's generally an option, again, in a university-type
setting, even if you had a unix box.
Thanks,
Stephen
Stephen Frost wrote: > * Magnus Hagander (magnus@hagander.net) wrote: >> Stephen Frost wrote: >>> I'm not quite sure if that would affect what we do but it sounds like it >>> might. The main thing we use on the clients wrt Postgres is the ODBC >>> driver but I've used psql once or twice and have been trying to get >>> people to learn it. >> ODBC driver should work with it - I don't know exactly how they plug >> into libpqs auth, but IIRC they do some stuff to make that work. > > I wouldn't be so sure... I'm not exactly a fan of how ODBC does that > anyway, it essentially uses libpq for the auth, *sometimes*, and then > hijacks the connection away. Yeah, I'm not a fan of that either, but as long as it works.. Which leads me to the question - does it work for GSSAPI? Anybody from the ODBC crowd who can comment on that? >> Note that I'm only talking about being mutually exclusiv ewith MIT KRB >> GSSAPI, not with MIT KRB in "krb5" mode. Though I very much want to >> deprecate the "native kerberos" auth in favor of GSSAPI as soon as >> possible for several reasons, so I'd suggest you don't use that once you >> go to 8.3 ;-) > > The KfW stuff from MIT provides both GSSAPI and 'native' kerberos, I > believe, and most things use the GSSAPI side of it, actually. We're pretty much the *only* major player who use "native" kerberos, AFAIK. Back two years ago (I think it was) I found a really trivial security hole in it (in the MIT code) that was exposed by a trivial user input error. If anybody else was using it, they'd have found that one long ago ;-) GSSAPI really is the way to go. >>> We've got SSPI which is used for the Windows domain (and only the windows >>> resources) and then MIT Krb5 GSSAPI for the Unix resources. While >>> cross-realm is a nice idea it's less than easy to get going, especially >>> with even a half-way secure key (I'm not exactly a big fan of >>> arc/rc4...). >> I have my Unix machines in the Active Directory, so there's no cross >> realm. It works fine. > > Yeah, that requires quite a bit more involvement between us and the > corporate folks, and means that we're dependent on them to do things > before we can do things. That tends to end badly. Heh. >> And if you don't trust the key, put it over SSL? ;-) If you use SSL, >> GSSAPI packets actually go through the SSL tunnel, unlike krb5 auth. > > Uhh, the client and the KDC don't generally use SSL to talk to each > other, last I checked, and the problem is with the cross-realm key (you > know, the one that you could use to fake anyone from the trusted realm) > having to be least-common-denominator between Windows and Unix since it > has to exist in both KDCs. That wouldn't be too much trouble if that > least-common-denominator was AES256 but at the moment it's not. Hm, Ok, thought you meant client<->server. Anyway, then use ipsec :-) >>> Additionally, it seems likely to me that there will be cases when people >>> running Windows don't *want* to set up an Active Directory for their >>> Windows machines but want to use Kerberos to auth to certain resources >>> (perhaps a campus environment where student systems aren't joined to an >>> AD domain?). Would that be possible with this? I havn't done much w/ >>> SSPI so I'm not sure how deeply that's tied into things like that. >> Yes, there's still support for doing GSSAPI with MIT KRB5. It's just >> that you have to use it *instead* of SSPI. So a rebuild is necessary. > > 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. > 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? //Magnus
* Magnus Hagander (magnus@hagander.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... 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. :)
> > 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. 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.
Thanks,
Stephen
Stephen Frost wrote: > * Magnus Hagander (magnus@hagander.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
* Magnus Hagander (magnus@hagander.net) wrote:
> Stephen Frost wrote:
> > 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.
I don't think SSPI supports having seperate credential caches, a
different default realm, etc...
(and I'm not sure how you'd set them up even if it did).
> One reason is that bringing in and configuring the MIT libraries is a
> significant overhead.
Erm, isn't this what's done now? Are we actually overloaded in some way
on the buildds? Would this actually be a measurable reduction in the
overhead of the buildds? I find this argument less than convincing
reasoning for dropping existing functionality...
> Nothing would prevent you from building your own DLL with Kerberos linking.
Except when it breaks because it's not being tested in the build
system... :/ I expect there are other such things in the same situation
but I'm rather unhappy that it's something which is actually going to
impact people (at the least me) as opposed to GNU readline on some
esoteric architecture.
> > 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.
MSVC would be a rather unhappy requirement. Do we have buildds running
with MingW? Settings up buildds is documented, etc, no? I don't know
if I could dedicate a machine to it but at least if I can build my own
buildd setup using the scripts and whatnot it might not be too bad..
> > 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.
If the ODBC driver doesn't support changes to the connectionstring (and
I think it does, actually), that'd probably be a sensible thing to add
anyway. Having to have what's essentially a library-config option
handled by all the clients does kind of suck though.
> As I'm sure you can tell, I'm far from convinced this is a good idea ;-)
It's also not exactly unheard of. I'm pretty sure what mozilla does is
basically just dlopen() the appropriate library. I'm not sure if it's
even got an internal set of dlls which link to the sspi/gssapi dlls
explicitly. If it does we might be able to swipe it. Sorry for my lack
of familiarity, but does SSPI provide a GSSAPI identical to the MIT one?
For some reason I was thinking it did (hence why the dll magic just
works, but there could be more going on in those possibly) in which case
I'm not even sure you'd need the MIT stuff available to compile with
support for it?
> Anybody else want to comment on this?
I've always been rather unhappy at the apparent lack of user participation
on this list. :/ I don't mean to imply that I speak for the silent
majority, just that it's frustrating when trying to gauge the impact
of changes.
Thanks,
Stephen
Magnus Hagander wrote: > 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? The ODBC driver would need modification (as would pgAdmin of course). Whats more of a concern is that we already have ODBC connection strings that can be too long - adding yet another option will make that worse of course. Regards, Dave
Stephen Frost wrote: > * Magnus Hagander (magnus@hagander.net) wrote: >> Stephen Frost wrote: >>> 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. > > I don't think SSPI supports having seperate credential caches, a > different default realm, etc... > (and I'm not sure how you'd set them up even if it did). No, it does not. But that in itself has nothing to do with GSSAPI - your requirement is something different. That's not saying we should ignore your requirement :-) >> One reason is that bringing in and configuring the MIT libraries is a >> significant overhead. > > Erm, isn't this what's done now? Except you don't need to configure it unless you use it, but yes, it's an overhead we have now. That I would very much like to get rid of. > Are we actually overloaded in some way > on the buildds? Would this actually be a measurable reduction in the > overhead of the buildds? I find this argument less than convincing > reasoning for dropping existing functionality... Yes. It's a pain to get the kerberos stuff set up :-( >> Nothing would prevent you from building your own DLL with Kerberos linking. > > Except when it breaks because it's not being tested in the build > system... :/ I expect there are other such things in the same situation > but I'm rather unhappy that it's something which is actually going to > impact people (at the least me) as opposed to GNU readline on some > esoteric architecture. Say what? You'd still get them tested on any BF member that configures it. Just like now - you won't get it tested unless the BF member is specifically configured to get it. The only difference is that the SSPI code *would* get tested even if you don't specifically configure it. We can easily make sure that at we have BF coverage of the feature. It's also the same codepath that would be used on Unix, so you'd get that coverage as well - not complete, but a good part of the way. >>> 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. > > MSVC would be a rather unhappy requirement. Why? But again, you can do mingw if you want to. > Do we have buildds running > with MingW? Settings up buildds is documented, etc, no? I don't know > if I could dedicate a machine to it but at least if I can build my own > buildd setup using the scripts and whatnot it might not be too bad.. I have no idea even what buildds is, so I can't comment on if it works with mingw :-) >>> 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. > > If the ODBC driver doesn't support changes to the connectionstring (and > I think it does, actually), that'd probably be a sensible thing to add > anyway. Having to have what's essentially a library-config option > handled by all the clients does kind of suck though. The only other option I can think of is an environment variable, which seems very un-windowsy. But we could have something like "sent environment variable PG_GSSAPI=mit" and then attempt to dynamically load the kerberos libraries. Specifically for win32. It's a bit of a kludge, and it'll certainly add more code, but it's not *hard* to do. It will keep the overhead for the builder of the distribution (hello, Dave) since it will still require the headers to be present on the build machine, but not for end-users that don't want it (assuming we stop shipping the MIT DLLs in the package, which I'd like to do). Also, remember that there is no actual testing of it on the BF. We don't test the functionality today on the BF, but at least we detect link-time errors ;-) >> As I'm sure you can tell, I'm far from convinced this is a good idea ;-) > > It's also not exactly unheard of. I'm pretty sure what mozilla does is > basically just dlopen() the appropriate library. I'm not sure if it's > even got an internal set of dlls which link to the sspi/gssapi dlls > explicitly. If it does we might be able to swipe it. Sorry for my lack > of familiarity, but does SSPI provide a GSSAPI identical to the MIT one? GSSAPI protocol, yes. GSSAPI API, no. > For some reason I was thinking it did (hence why the dll magic just > works, but there could be more going on in those possibly) in which case > I'm not even sure you'd need the MIT stuff available to compile with > support for it? You don't need it to do GSSAPI authentication, no. You do need it if you need to do non-windows GSSAPI authentication. Such as your case when you want to authenticate to a realm that your windows system is not a part of. >> Anybody else want to comment on this? > > I've always been rather unhappy at the apparent lack of user participation > on this list. :/ I don't mean to imply that I speak for the silent > majority, just that it's frustrating when trying to gauge the impact > of changes. Yeah, that is a problem... I can only speak for my self and those that I have worked with/talked to, and you are the first one I've heard of that actually *prefers* using the MIT libraries if there's another option available on Windows. So it's good that you do speak up :) //Magnus
Dave Page wrote: > Magnus Hagander wrote: >> 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? > > The ODBC driver would need modification (as would pgAdmin of course). > Whats more of a concern is that we already have ODBC connection strings > that can be too long - adding yet another option will make that worse of > course. Interesting, didn't know that. That makes that option even less interesting. Can you comment on if the current ODBC driver will pick up GSSAPI authentication from libpq or if it needs new code to deal with it? I never quite figured out how they integrate with libpq for the authentication part since it moved away from using libpq for everything again. //Magnus
This is great. I've worked on 2 projects in the last year that desperately needed this. It will certainly make the security model more seamless... -Paul Magnus Hagander-2 wrote: > > A quick status update on the SSPI authentication part of the GSSAPI > project. > > I have libpq SSPI working now, with a few hardcoded things still in > there to be fixed. But it means that I can connect to a linux server > using kerberos/GSSAPI *without* the need to set up MIR Kerberos > libraries and settings on the client. This is great :-) The code is > fairly trivial. > > I've set it up as a different way of doing GSSAPI authentication. This > means that if you can't have both SSPI and MIT KRB GSSAPI in the same > installation. I don't see a problem with this - 99.9% of windows users > will just want the SSPI version anyway. But I figured I'd throw it out > here to see if there are any objections to this? > > I'd like to make this enabled by default on Win32, since all supported > windows platforms have support for it. Then we can add a configure > option to turn it *off* if we want to. Comments? Do we even need such an > option? > > Right now, the SSPI path is hardcoded to just support Kerberos. Once we > have both client and server with SSPI support I see no reason to keep > this restriction. Anybody against that? (Not saying that'll happen for > 8.3, because it certainly needs a bunch of extra testing, but eventually) > > > //Magnus > > ---------------------------(end of broadcast)--------------------------- > TIP 6: explain analyze is your friend > > -- View this message in context: http://www.nabble.com/SSPI-authentication-tf4090227.html#a11654750 Sent from the PostgreSQL - hackers mailing list archive at Nabble.com.
Magnus Hagander wrote: > Dave Page wrote: >> Magnus Hagander wrote: >>> 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? >> The ODBC driver would need modification (as would pgAdmin of course). >> Whats more of a concern is that we already have ODBC connection strings >> that can be too long - adding yet another option will make that worse of >> course. > > Interesting, didn't know that. That makes that option even less interesting. > > Can you comment on if the current ODBC driver will pick up GSSAPI > authentication from libpq or if it needs new code to deal with it? I > never quite figured out how they integrate with libpq for the > authentication part since it moved away from using libpq for everything > again. It should 'just work' I guess - it does for the existing Kerberos support. I never really studied GSSAPI though so I may be missing some fundamental point. /D
On Wed, Jul 18, 2007 at 09:44:02AM +0100, Dave Page wrote: > Magnus Hagander wrote: > > Dave Page wrote: > >> Magnus Hagander wrote: > >>> 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? > >> The ODBC driver would need modification (as would pgAdmin of course). > >> Whats more of a concern is that we already have ODBC connection strings > >> that can be too long - adding yet another option will make that worse of > >> course. > > > > Interesting, didn't know that. That makes that option even less interesting. > > > > Can you comment on if the current ODBC driver will pick up GSSAPI > > authentication from libpq or if it needs new code to deal with it? I > > never quite figured out how they integrate with libpq for the > > authentication part since it moved away from using libpq for everything > > again. > > It should 'just work' I guess - it does for the existing Kerberos > support. I never really studied GSSAPI though so I may be missing some > fundamental point. Ok, I got around to do some testing and it works perfectly fine. At least on Windows - don't have ODBC set up anywhere else. But on windows + the SSPI patch I just posted I get integrated login without any problems from a vbscript using ODBC. Driver version 8.1 even :-) //Magnus
On Tue, Jul 17, 2007 at 11:00:35AM -0700, Paul Silveira wrote: > > This is great. I've worked on 2 projects in the last year that desperately > needed this. It will certainly make the security model more seamless... Thanks for letting us know. Are you interested in just the SSPI parts, or also in being able to use both SSPI and GSSAPI at the same time? //Magnus
Just the SSPI piece. Right now we run a mixture of PostgreSQL and SQL Server and the one fustrating thing is that we have to have separate security architectures for them. The SQL Server environment is nice because it allows SSPI and eliminates the need to pass around passwords everywhere. In the postgres environment, we've worked around that by "Trusting" the postgres user from certain locked down and protected IP addresses so that we don't need to store passwords but that would never win any security awards. :) SSPI will enable us to create services that run as that registered user and as long as that user can obtain an authenticated kerb ticket, we can ensure that are the user they say they are. Much nicer model... Looking forward to this release. When will it be available? Paul -----Original Message----- From: Magnus Hagander [mailto:magnus@hagander.net] Sent: Wednesday, July 18, 2007 6:42 AM To: Paul Silveira Cc: pgsql-hackers@postgresql.org Subject: Re: [HACKERS] SSPI authentication On Tue, Jul 17, 2007 at 11:00:35AM -0700, Paul Silveira wrote: > > This is great. I've worked on 2 projects in the last year that desperately > needed this. It will certainly make the security model more seamless... Thanks for letting us know. Are you interested in just the SSPI parts, or also in being able to use both SSPI and GSSAPI at the same time? //Magnus