Re: [HACKERS] SSPI authentication
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 ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] SSPI authentication
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 ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
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 ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] SSPI authentication
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:[EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] SSPI authentication
Stephen Frost wrote: * Magnus Hagander ([EMAIL PROTECTED]) 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 ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] SSPI authentication
* Magnus Hagander ([EMAIL PROTECTED]) 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 signature.asc Description: Digital signature
Re: [HACKERS] SSPI authentication
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 ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] SSPI authentication
Stephen Frost wrote: * Magnus Hagander ([EMAIL PROTECTED]) 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
Re: [HACKERS] SSPI authentication
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 ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] SSPI authentication
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. ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
[HACKERS] 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 ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] SSPI authentication
* Magnus Hagander ([EMAIL PROTECTED]) 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 signature.asc Description: Digital signature
Re: [HACKERS] SSPI authentication
Stephen Frost wrote: * Magnus Hagander ([EMAIL PROTECTED]) 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 ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] SSPI authentication
* Magnus Hagander ([EMAIL PROTECTED]) 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 signature.asc Description: Digital signature
Re: [HACKERS] SSPI authentication
Stephen Frost wrote: * Magnus Hagander ([EMAIL PROTECTED]) 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 ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] SSPI authentication
* Magnus Hagander ([EMAIL PROTECTED]) 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 signature.asc Description: Digital signature
