Future of krb5 authentication

Magnus Hagander wrote:

Now that we have working GSSAPI authentication, I'd like to see the
following done:

* Deprecate krb5 authentication in 8.3. At least in documentation, possibly
with a warning when loading pg_hba.conf?
* Remove krb5 authenticatino completely in 8.4.

libpq would still work against older server versions, right?

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

On Wed, Jul 18, 2007 at 11:45:19AM +0100, Heikki Linnakangas wrote:

Magnus Hagander wrote:

Now that we have working GSSAPI authentication, I'd like to see the
following done:

* Deprecate krb5 authentication in 8.3. At least in documentation, possibly
with a warning when loading pg_hba.conf?
* Remove krb5 authenticatino completely in 8.4.

libpq would still work against older server versions, right?

Not once krb5 is removed. Assuming the older server version used krb5 auth.
I want to remove it from both libpq and the server.
(8.3 libpq would of course work with older versions, since it's only
deprecated at that point)

I guess a compromise would be to remove it from the server in 8.4 and libpq
in 8.5 or so, if people think that it's a problem. But I think we definitly
want to get it out of libpq as well eventually.

//Magnus

Magnus Hagander wrote:

libpq would still work against older server versions, right?

Not once krb5 is removed. Assuming the older server version used krb5 auth.

OK, well thats a problem. pgAdmin supports back to 7.3...

/D

On Wed, Jul 18, 2007 at 11:57:19AM +0100, Dave Page wrote:

Magnus Hagander wrote:

libpq would still work against older server versions, right?

Not once krb5 is removed. Assuming the older server version used krb5 auth.

OK, well thats a problem. pgAdmin supports back to 7.3...

You have a similar problem there already - 8.1 removed support for Kerberos
4, so if your 7.3 server is configged with krb4, you loose anyway.

//Magnus

Magnus Hagander wrote:

On Wed, Jul 18, 2007 at 11:57:19AM +0100, Dave Page wrote:

Magnus Hagander wrote:

libpq would still work against older server versions, right?

Not once krb5 is removed. Assuming the older server version used krb5 auth.

OK, well thats a problem. pgAdmin supports back to 7.3...

You have a similar problem there already - 8.1 removed support for Kerberos
4, so if your 7.3 server is configged with krb4, you loose anyway.

We never shipped krb4 support in any of our self contained binary
distros (I'm not counting those which rely on external libpq packages).

Regards, Dave

Magnus Hagander wrote:

On Wed, Jul 18, 2007 at 11:57:19AM +0100, Dave Page wrote:

Magnus Hagander wrote:

libpq would still work against older server versions, right?

Not once krb5 is removed. Assuming the older server version used krb5 auth.

OK, well thats a problem. pgAdmin supports back to 7.3...

You have a similar problem there already - 8.1 removed support for Kerberos
4, so if your 7.3 server is configged with krb4, you loose anyway.

Let's be practical here. We're going to have support for both in libpq
for at least one version anyway. What do we gain by removing that
support in a later release? I think we should just keep it around until
we have a pressing reason to remove it, say if it gets in the way of
implementing some new feature.

In the server, I think we could remove it sooner. But even there, is
there a reason why we should?

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

On Wed, Jul 18, 2007 at 12:16:49PM +0100, Heikki Linnakangas wrote:

Magnus Hagander wrote:

On Wed, Jul 18, 2007 at 11:57:19AM +0100, Dave Page wrote:

Magnus Hagander wrote:

libpq would still work against older server versions, right?

Not once krb5 is removed. Assuming the older server version used krb5 auth.

OK, well thats a problem. pgAdmin supports back to 7.3...

You have a similar problem there already - 8.1 removed support for Kerberos
4, so if your 7.3 server is configged with krb4, you loose anyway.

Let's be practical here. We're going to have support for both in libpq
for at least one version anyway. What do we gain by removing that
support in a later release? I think we should just keep it around until
we have a pressing reason to remove it, say if it gets in the way of
implementing some new feature.

In the server, I think we could remove it sooner. But even there, is
there a reason why we should?

The main reasons would be to have less code to maintain, and to make life
easier for packagers. For example, win32 would no longer need to ship the
kerberos binaries in the package (and update it properly etc).

But sure, we might leave it in there until there's a direct problem with it
(other than the ones we already know). Can I still get my deprecation of it
though? ;-)

//Magnus

Magnus Hagander wrote:

But sure, we might leave it in there until there's a direct problem with it
(other than the ones we already know). Can I still get my deprecation of it
though? ;-)

I'm not sure what the deprecation would mean in the client-side. You're
going to need it if you want to connect to a server that uses it,
there's no alternative.

In the server, I don't see a problem with it. What would the deprecation
mean, though? Mention in the docs that it's going to removed sometime in
the future? A warning if you enable it?

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

On Wed, Jul 18, 2007 at 12:26:28PM +0100, Heikki Linnakangas wrote:

Magnus Hagander wrote:

But sure, we might leave it in there until there's a direct problem with it
(other than the ones we already know). Can I still get my deprecation of it
though? ;-)

I'm not sure what the deprecation would mean in the client-side. You're
going to need it if you want to connect to a server that uses it,
there's no alternative.

No, it would mean nothing on the client.

In the server, I don't see a problem with it. What would the deprecation
mean, though? Mention in the docs that it's going to removed sometime in
the future? A warning if you enable it?

At least a warning in the docs. And possibly also a warning when you enable
it, depending on what people thing is appropriate.

//Magnus

Dave Page wrote:

Magnus Hagander wrote:

libpq would still work against older server versions, right?

Not once krb5 is removed. Assuming the older server version used krb5
auth.

OK, well thats a problem. pgAdmin supports back to 7.3...

I think you need to put forward an alternative plan, then. Asking us to
wait until your oldest version is 8.4 before we rip it out of libpq
doesn't sound too good.

cheers

andrew

Andrew Dunstan wrote:

Dave Page wrote:

Magnus Hagander wrote:

libpq would still work against older server versions, right?

Not once krb5 is removed. Assuming the older server version used krb5
auth.

OK, well thats a problem. pgAdmin supports back to 7.3...

I think you need to put forward an alternative plan, then. Asking us to
wait until your oldest version is 8.4 before we rip it out of libpq
doesn't sound too good.

pgAdmin was just one example. This prevents anyone with kerberos5 in a
similar situation upgrading their client libraries - including users of
the myriad of apps that use psqlODBC.

Regards, Dave

Am Mittwoch, 18. Juli 2007 13:21 schrieb Magnus Hagander:

The main reasons would be to have less code to maintain,

I don't think the krb5 support has needed all that much maintenance in the
last few years.

and to make life
easier for packagers. For example, win32 would no longer need to ship the
kerberos binaries in the package (and update it properly etc).

Nobody is forcing anyone to ship anything anyway.

But sure, we might leave it in there until there's a direct problem with it
(other than the ones we already know). Can I still get my deprecation of it
though? ;-)

You might want to inquire about that on -general.

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

Dave Page wrote:

Magnus Hagander wrote:

libpq would still work against older server versions, right?

Not once krb5 is removed. Assuming the older server version used krb5
auth.

OK, well thats a problem. pgAdmin supports back to 7.3...

How many people actually use kerberos... How many people who are using
kerberos are going to be running 7.3. 7.3 is no longer supported so by
postgresql.org so who cares.

Joshua D. Drake

Dave Page wrote:

Andrew Dunstan wrote:

Dave Page wrote:

Magnus Hagander wrote:

libpq would still work against older server versions, right?

Not once krb5 is removed. Assuming the older server version used
krb5 auth.

OK, well thats a problem. pgAdmin supports back to 7.3...

I think you need to put forward an alternative plan, then. Asking us
to wait until your oldest version is 8.4 before we rip it out of libpq
doesn't sound too good.

pgAdmin was just one example. This prevents anyone with kerberos5 in a
similar situation upgrading their client libraries - including users of
the myriad of apps that use psqlODBC.

Who likely don't use kerberos.

Joshua D. Drake

Joshua D. Drake wrote:

pgAdmin was just one example. This prevents anyone with kerberos5 in a
similar situation upgrading their client libraries - including users
of the myriad of apps that use psqlODBC.

Who likely don't use kerberos.

Probably not in the majority of cases - but we have a large userbase
these days, and a small percentage may still equate to a large number. I
know at least two people that do use psqlODBC + Kerberos.

Regards, Dave

Magnus Hagander <magnus@hagander.net> writes:

But sure, we might leave it in there until there's a direct problem with it
(other than the ones we already know). Can I still get my deprecation of it
though? ;-)

In the krb4 case, we left it in there until there was very little
probability anyone was using it anymore, and AFAIR there was no
significant maintenance burden from that. I don't see a reason to be
harsher on the krb5 case.

The real problem in my mind is this business of the gssapi and krb5
support being mutually exclusive. That is going to cause tremendous
pain because there won't be any convenient upgrade path. Particularly
not for users of binary packages (RPMs etc) --- they'll be screwed
if their packager changes, and have no way to upgrade if he doesn't.
This needs to be fixed.

regards, tom lane

peter_e@gmx.net (Peter Eisentraut) writes:

Am Mittwoch, 18. Juli 2007 13:21 schrieb Magnus Hagander:

The main reasons would be to have less code to maintain,

I don't think the krb5 support has needed all that much maintenance in the
last few years.

and to make life
easier for packagers. For example, win32 would no longer need to ship the
kerberos binaries in the package (and update it properly etc).

Nobody is forcing anyone to ship anything anyway.

But on the other hand, if support for something gets "ripped out,"
that pretty much forces packagers to NOT ship it anymore. So it's not
totally symmetrical...

But sure, we might leave it in there until there's a direct problem with it
(other than the ones we already know). Can I still get my deprecation of it
though? ;-)

You might want to inquire about that on -general.

Good idea...

--
let name="cbbrowne" and tld="linuxfinances.info" in String.concat "@" [name;tld];;
http://www3.sympatico.ca/cbbrowne/internet.html
"This must be Thursday. I never could get the hang of Thursdays."
- Arthur Dent

On Wed, Jul 18, 2007 at 10:46:58AM -0400, Tom Lane wrote:

Magnus Hagander <magnus@hagander.net> writes:

But sure, we might leave it in there until there's a direct problem with it
(other than the ones we already know). Can I still get my deprecation of it
though? ;-)

In the krb4 case, we left it in there until there was very little
probability anyone was using it anymore, and AFAIR there was no
significant maintenance burden from that. I don't see a reason to be
harsher on the krb5 case.

The real problem in my mind is this business of the gssapi and krb5
support being mutually exclusive. That is going to cause tremendous
pain because there won't be any convenient upgrade path. Particularly
not for users of binary packages (RPMs etc) --- they'll be screwed
if their packager changes, and have no way to upgrade if he doesn't.
This needs to be fixed.

Non, GSSAPI and krb5 are *not* mutually exclusive.

SSPI and GSSAPI are mutually exclusive.

You can use krb5 and GSSAPI or krb5 and SSPI just fine.

//Magnus

Magnus Hagander <magnus@hagander.net> writes:

On Wed, Jul 18, 2007 at 10:46:58AM -0400, Tom Lane wrote:

This needs to be fixed.

Non, GSSAPI and krb5 are *not* mutually exclusive.

SSPI and GSSAPI are mutually exclusive.

Color me confused then. What's the difference?

regards, tom lane

Joshua D. Drake wrote:

Dave Page wrote:

Andrew Dunstan wrote:

Dave Page wrote:

Magnus Hagander wrote:

libpq would still work against older server versions, right?

Not once krb5 is removed. Assuming the older server version used
krb5 auth.

OK, well thats a problem. pgAdmin supports back to 7.3...

I think you need to put forward an alternative plan, then. Asking us
to wait until your oldest version is 8.4 before we rip it out of
libpq doesn't sound too good.

pgAdmin was just one example. This prevents anyone with kerberos5 in a
similar situation upgrading their client libraries - including users
of the myriad of apps that use psqlODBC.

Who likely don't use kerberos.

I would also note that Magnus's proposal means that krb5 won't be
removed for *at least* 2 years. I think that is plenty of time for an
EOL cycle on a feature.

Joshua D. Drake

"Tom Lane" <tgl@sss.pgh.pa.us> writes:

The real problem in my mind is this business of the gssapi and krb5
support being mutually exclusive.

Oh, I didn't catch that. That's wrong anyways, there could be multiple
applications on the same machine, some of which use krb4 and some which use
gssapi.

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com

Tom Lane wrote:

Magnus Hagander <magnus@hagander.net> writes:

On Wed, Jul 18, 2007 at 10:46:58AM -0400, Tom Lane wrote:

This needs to be fixed.

Non, GSSAPI and krb5 are *not* mutually exclusive.

SSPI and GSSAPI are mutually exclusive.

Color me confused then. What's the difference?

SSPI is a Windows-only implementation of the GSSAPI protocol, that has a
different API.

GSSAPI works on Unix and on Windows (but only with addon libraries, such
as MIT (unix or win) or Heimdal (unix only)).

The confusion probably comes from that GSSAPI is both a protocol
(supported by SSPI as well) and an API (not supported by SSPI).

Now, SSPI integrates with Active Directory, so it doesn't work if you
don't want to join your workstation to the Kerberos realm. Or as in
Stephens case, you want to be *both* on the Active Directory and in a
non-trusted Unix Kerberos realm.

But we're talking two different issues. Deprecating/removing krb5 is a
different thing from having GSSAPI and SSPI mutually exclusive or not.

//Magnus

* Tom Lane (tgl@sss.pgh.pa.us) wrote:

Magnus Hagander <magnus@hagander.net> writes:

On Wed, Jul 18, 2007 at 10:46:58AM -0400, Tom Lane wrote:

This needs to be fixed.

Non, GSSAPI and krb5 are *not* mutually exclusive.

SSPI and GSSAPI are mutually exclusive.

Color me confused then. What's the difference?

GSSAPI is the MIT libraries, SSPI is the Windows library, but there's no
way to indicate to libpq which to use and they share some of the same
code paths with minor adjustments for each done at compile-time (aiui
anyway, Magnus can provide a clearer answer on this).

The feeling was that because there's no way to indicate to libpq which
to use except through the connectionstring and that most people would
want SSPI instead and that krb5 support is going to be removed that we
could just support either SSPI or GSSAPI (not both).

My feeling is that if we're going to continue to support krb5 *anyway*
(which I don't disagree with, honestly) then the GSSAPI stuff is going
to be required for the build *regardless* and therefore it makes sense
to support both in libpq rather than making them mutually exclusive.
Supporting it using a connectionstring option would be sufficient, imv,
though downstream utilities that don't let you modify the
connectionstring directly would have to add support for it (I'm of the
opinion that such things should be changed to allow a connectionstring
option, or at least an append to it, but perhaps there's some reason
that's a problem for some).

GSSAPI and SSPI are not, themselves, mutually exclusive. They're just
being made that way by the libpq code that's been proposed. Mozilla
handles doing both just fine and you flip between them using an option
in their 'about:config' screen.

Thanks,

Stephen

* Magnus Hagander (magnus@hagander.net) wrote:

But we're talking two different issues. Deprecating/removing krb5 is a
different thing from having GSSAPI and SSPI mutually exclusive or not.

To the extent that keeping krb5 around implies a much lower burden on
GSSAPI support under Windows, I disagree... If we need the MIT
headers/libraries around to support krb5 anyway then I don't feel the
fact that you can do SSPI w/o those headers/libraries to be a case for
not supporting GSSAPI on Windows, we need them anyway...

Thanks,

Stephen

* Dave Page (dpage@postgresql.org) wrote:

Probably not in the majority of cases - but we have a large userbase these
days, and a small percentage may still equate to a large number. I know at
least two people that do use psqlODBC + Kerberos.

I certainly use it alot! Of course, we'll move to GSSAPI, assuming
that's not too difficult for us to do under Windows...

Thanks,

Stephen

* Joshua D. Drake (jd@commandprompt.com) wrote:

OK, well thats a problem. pgAdmin supports back to 7.3...

How many people actually use kerberos... How many people who are using
kerberos are going to be running 7.3. 7.3 is no longer supported so by
postgresql.org so who cares.

AOL, MIT, CMU, to name a few... I'm really annoyed at these constant
digs at what is really a very large userbase. Perhaps they're not all
running 7.3 but the implication that there's a small number of people
using Kerberos is just amazingly far off.

Thanks,

Stephen

Stephen Frost wrote:

* Magnus Hagander (magnus@hagander.net) wrote:

But we're talking two different issues. Deprecating/removing krb5 is a
different thing from having GSSAPI and SSPI mutually exclusive or not.

To the extent that keeping krb5 around implies a much lower burden on
GSSAPI support under Windows, I disagree... If we need the MIT
headers/libraries around to support krb5 anyway then I don't feel the
fact that you can do SSPI w/o those headers/libraries to be a case for
not supporting GSSAPI on Windows, we need them anyway...

I was talking from a technical perspective, not a maintenance one.

Your argument is at least party valid - though Dave has reported major
issues due to the gssapi library changing between versions. But those
are solvable.

The maintenance part of me suggesting getting rid of krb5 is the
smallest one. It being a non-standard protocol is more important, and
the fact that the exchange breaks the libpq protocol and is not
protected by SSL is the big reason.

But none of those more important reasons speak for removing krb5 - just
deprecating it. So I'm fine with doing that.

(and again, the SSPI vs GSSAPI on win32 discussion is a different one)

//Magnus

Stephen Frost wrote:

* Tom Lane (tgl@sss.pgh.pa.us) wrote:

Magnus Hagander <magnus@hagander.net> writes:

On Wed, Jul 18, 2007 at 10:46:58AM -0400, Tom Lane wrote:

This needs to be fixed.

Non, GSSAPI and krb5 are *not* mutually exclusive.
SSPI and GSSAPI are mutually exclusive.

Color me confused then. What's the difference?

GSSAPI is the MIT libraries, SSPI is the Windows library, but there's no
way to indicate to libpq which to use and they share some of the same
code paths with minor adjustments for each done at compile-time (aiui
anyway, Magnus can provide a clearer answer on this).

Certainly not "just minor adjustments", since we need to do dynamic
loading and checking for the functions. That's the big one, which will
certainly increase the required code a lot. The part about letting the
client specify how is probably fairly easy, if we can figure out a good
one. (I personally think we've clearly shown that using the
connectionstring is not a good enough way to do it)

//Magnus

* Magnus Hagander (magnus@hagander.net) wrote:

The maintenance part of me suggesting getting rid of krb5 is the
smallest one. It being a non-standard protocol is more important, and
the fact that the exchange breaks the libpq protocol and is not
protected by SSL is the big reason.

Erm, it doesn't need to be protected by SSL? Breaking the libpq
protocol does kind of suck. I assume you're not requiring SSL for the
GSSAPI stuff...

Thanks,

Stephen

* Magnus Hagander (magnus@hagander.net) wrote:

Certainly not "just minor adjustments", since we need to do dynamic
loading and checking for the functions. That's the big one, which will

If we're supporting krb5 anyway, and shipping the bits that go along
with that, do we need to do dynamic loading and function checking?

Thanks,

Stephen

Stephen Frost wrote:

* Magnus Hagander (magnus@hagander.net) wrote:

The maintenance part of me suggesting getting rid of krb5 is the
smallest one. It being a non-standard protocol is more important, and
the fact that the exchange breaks the libpq protocol and is not
protected by SSL is the big reason.

Erm, it doesn't need to be protected by SSL? Breaking the libpq
protocol does kind of suck. I assume you're not requiring SSL for the
GSSAPI stuff...

No, no requirement. But you would certainly expect it to use it if you
have SSL on the connection.

//Magnus

Stephen Frost wrote:

* Magnus Hagander (magnus@hagander.net) wrote:

Certainly not "just minor adjustments", since we need to do dynamic
loading and checking for the functions. That's the big one, which will

If we're supporting krb5 anyway, and shipping the bits that go along
with that, do we need to do dynamic loading and function checking?

Eh, good point. I got confused, it seems :-) Scratch that, then - we're
back to finding a good way to specify it.

//Magnus

Stephen Frost wrote:

* Joshua D. Drake (jd@commandprompt.com) wrote:

OK, well thats a problem. pgAdmin supports back to 7.3...

How many people actually use kerberos... How many people who are using
kerberos are going to be running 7.3. 7.3 is no longer supported so by
postgresql.org so who cares.

AOL, MIT, CMU, to name a few... I'm really annoyed at these constant
digs at what is really a very large userbase. Perhaps they're not all
running 7.3 but the implication that there's a small number of people
using Kerberos is just amazingly far off.

*cough* , compared to the number of installations *not* using kerberos
it is amazing that you would make such a far off correlation.

Note that we are talking about Kerberos + PostgreSQL, not Kerberose in
general.

Joshua D. Drake

Thanks,

Stephen

--

=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/

Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
PostgreSQL Replication: http://www.commandprompt.com/products/

* Magnus Hagander (magnus@hagander.net) wrote:

No, no requirement. But you would certainly expect it to use it if you
have SSL on the connection.

Uhh, perhaps, but my recollection is that it's generally *not* done that
way in other things.. Honestly, it doesn't matter to me, just wanted to
clear up the implication.

Thanks,

Stephen

* Magnus Hagander (magnus@hagander.net) wrote:

Stephen Frost wrote:

* Magnus Hagander (magnus@hagander.net) wrote:

Certainly not "just minor adjustments", since we need to do dynamic
loading and checking for the functions. That's the big one, which will

If we're supporting krb5 anyway, and shipping the bits that go along
with that, do we need to do dynamic loading and function checking?

Eh, good point. I got confused, it seems :-) Scratch that, then - we're
back to finding a good way to specify it.

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.

I'd also use that as an opportunity to encourage applications to expose
the connectionstring to users as there may be things like this in the
future where it's purely a library thing and the application doesn't
have to know about it- except for the connectionstring.

Thanks,

Stephen

* Joshua D. Drake (jd@commandprompt.com) wrote:

Stephen Frost wrote:

* Joshua D. Drake (jd@commandprompt.com) wrote:

How many people actually use kerberos... How many people who are using
kerberos are going to be running 7.3. 7.3 is no longer supported so by
postgresql.org so who cares.

AOL, MIT, CMU, to name a few... I'm really annoyed at these constant
digs at what is really a very large userbase. Perhaps they're not all
running 7.3 but the implication that there's a small number of people
using Kerberos is just amazingly far off.

*cough* , compared to the number of installations *not* using kerberos it
is amazing that you would make such a far off correlation.

Oh, yea, and every place that uses Active Directory ..

Note that we are talking about Kerberos + PostgreSQL, not Kerberose in
general.

I was referring to your first question, which, in my view, is the more
appropriate one *anyway*. At least if you have a "PostgreSQL is going
to dominate the WORLD!" point of view, as I do. :)

Thanks,

Stephen

Stephen Frost wrote:

* Joshua D. Drake (jd@commandprompt.com) wrote:

Oh, yea, and every place that uses Active Directory ..

Note that we are talking about Kerberos + PostgreSQL, not Kerberose in
general.

I was referring to your first question, which, in my view, is the more
appropriate one *anyway*. At least if you have a "PostgreSQL is going
to dominate the WORLD!" point of view, as I do. :)

Of course I do. I am just a realist and know that isn't going to happen
on Win32 ;)

Joshua D. Drake

Thanks,

Stephen

--

=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/

Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
PostgreSQL Replication: http://www.commandprompt.com/products/

Stephen Frost wrote:

* Magnus Hagander (magnus@hagander.net) wrote:

Stephen Frost wrote:

* Magnus Hagander (magnus@hagander.net) wrote:

Certainly not "just minor adjustments", since we need to do dynamic
loading and checking for the functions. That's the big one, which will

If we're supporting krb5 anyway, and shipping the bits that go along
with that, do we need to do dynamic loading and function checking?

Eh, good point. I got confused, it seems :-) Scratch that, then - we're
back to finding a good way to specify it.

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.

Well, since you're the only one who've asked for the feature, I guess
that's good enough for me unless someone else complains. If you have a
good suggestion for a name for it, let me know, otherwise I'll just cook
something up.

BTW, I have working SSPI server code running on Windows now as well,
giving the full Active Directory integration in the windows postgresql.
It's far from perfect yet, needs a bunch of cleanup, but it works. (This
is SSPI, of course)

//Magnus

* Magnus Hagander (magnus@hagander.net) wrote:

Well, since you're the only one who've asked for the feature, I guess
that's good enough for me unless someone else complains. If you have a
good suggestion for a name for it, let me know, otherwise I'll just cook
something up.

Mozilla uses 'gsslib', that would work for me.

ie:

gsslib=gss
gsslib=sspi

Also, thanks!

BTW, I have working SSPI server code running on Windows now as well,
giving the full Active Directory integration in the windows postgresql.
It's far from perfect yet, needs a bunch of cleanup, but it works. (This
is SSPI, of course)

Awesome! Very exciting. :)

Thanks,

Stephen

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.

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

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.

//Magnus

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

* Heikki Linnakangas (heikki@enterprisedb.com) wrote:

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

It is kinda confusing. :)

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.

Well, I think it'll depend on what's configured, no? Doesn't the libpq
protocol say back to the user "this is what I want to use" or similar?
The impression I got was more along the lines of- we'll have another
option in pg_hba.conf for 'gssapi', distinct from 'krb5' and either
could be used. Might have misunderstood tho.

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.

No.. We used the MIT Krb5 library. This is a change to use the GSSAPI
library (also from MIT and part of their Kerberos distribution, so it's
a tad confusing) on Unix by default and compile in support for it under
Windows as well.

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?

You can't really 'fall back' without creating alot of noise in the logs
and whatnot. Also, it could try to do things that don't make any sense.
The reason to support both is that they have, essentially, different
feature sets.

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

No, at least from a user-interface standpoint and I think also the
wireline protocol is different...

Thanks,

Stephen

"Heikki Linnakangas" <heikki@enterprisedb.com> writes:

Magnus Hagander wrote:

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.

...
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?

Am I right in thinking that while the client<->postgres protocol may be the
same the actual authentication tokens are different? That is, if you have a
Windows Active Directory server then using SSPI will use your Windows
credentials obtained from that server to log you in whereas if you used the
MIT GSSAPI library it would try to use your Kerberos tickets for which it would
look elsewhere?

What confuses me here is that I don't understand how this relates to
applications. You keep talking about using the connection string which may be
appropriate for a user-oriented application like psql. But in the general case
surely the application needs to be able to control the authentication process
and be able to provide credentials of its choice?

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com

Magnus Hagander <magnus@hagander.net> writes:

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.

Oh, they're fully interchangeable at the wire level? Is this true both
with respect to the PG client/backend protocol and the protocol to the
authentication server? If there's no interoperability issues then I
agree that a configure-time choice is sufficient for selecting which
library to use.

regards, tom lane

* Gregory Stark (stark@enterprisedb.com) wrote:

Am I right in thinking that while the client<->postgres protocol may be the
same the actual authentication tokens are different? That is, if you have a
Windows Active Directory server then using SSPI will use your Windows
credentials obtained from that server to log you in whereas if you used the
MIT GSSAPI library it would try to use your Kerberos tickets for which it would
look elsewhere?

This *can* be true, and in fact is *exactly* what I do. The MIT client
comes with an option (enabled by default actually) to sync up the MIT
ticket cache with the SSPI one though.

What confuses me here is that I don't understand how this relates to
applications. You keep talking about using the connection string which may be
appropriate for a user-oriented application like psql. But in the general case
surely the application needs to be able to control the authentication process
and be able to provide credentials of its choice?

We're talking about user-oriented applications... Specifically things
like psql and Postgres ODBC, which use user's credentials to connect to
the database and don't have their own credentials...

Thanks,

Stephen

* Tom Lane (tgl@sss.pgh.pa.us) wrote:

Oh, they're fully interchangeable at the wire level? Is this true both
with respect to the PG client/backend protocol and the protocol to the
authentication server?

I believe that's the case, yes.

If there's no interoperability issues then I
agree that a configure-time choice is sufficient for selecting which
library to use.

In general I agree, but I'd like to see builds for Windows which support
them and I'm not sure that'll happen quite as regularly. :/

Aside from that issue though, if we're going to continue krb5 support
(which I'd encourage unless we have some reason to stop) and it's not
too much effort (I get the impression it's not) to support both
concurrently, I'd really appreciate it. :) I'm not aware of any 'funny
business' which would be involved in supporting them both at the same
time, and I believe Magnus is working on it.

Thanks,

Stephen

On Wed, Jul 18, 2007 at 06:01:33PM -0400, Stephen Frost wrote:

* Tom Lane (tgl@sss.pgh.pa.us) wrote:

Oh, they're fully interchangeable at the wire level? Is this true both
with respect to the PG client/backend protocol and the protocol to the
authentication server?

I believe that's the case, yes.

It is, as long as you use Kerberos auth.

It's of course not if you use SSPI with NTLM, but that's not surprising.

If there's no interoperability issues then I
agree that a configure-time choice is sufficient for selecting which
library to use.

In general I agree, but I'd like to see builds for Windows which support
them and I'm not sure that'll happen quite as regularly. :/

Well, again, that's fairly easy to do by setting up a buildfarm member.

Aside from that issue though, if we're going to continue krb5 support
(which I'd encourage unless we have some reason to stop) and it's not
too much effort (I get the impression it's not) to support both
concurrently, I'd really appreciate it. :) I'm not aware of any 'funny
business' which would be involved in supporting them both at the same
time, and I believe Magnus is working on it.

That is the point. It's going to be some more code, but that code will be
fairly trivial.

That's for client. How should we go about doing it on the server side?
Perhaps just add the ability to specify sspi as authentication method, to
differentiate it from gss?

//Magnus

* Magnus Hagander (magnus@hagander.net) wrote:

That's for client. How should we go about doing it on the server side?
Perhaps just add the ability to specify sspi as authentication method, to
differentiate it from gss?

That certainly works for me, and makes sense to me.

Thanks!

Stephen

On Thu, Jul 19, 2007 at 06:38:08AM -0400, Stephen Frost wrote:

* Magnus Hagander (magnus@hagander.net) wrote:

That's for client. How should we go about doing it on the server side?
Perhaps just add the ability to specify sspi as authentication method, to
differentiate it from gss?

That certainly works for me, and makes sense to me.

Ok, I actually have this working now, pending a few cleanups.

Do you have a dev box with 8.3 on it that you could run some tests on? I
could send over a libpq.dll compiled to support both GSSAPI and SSPI (and
krb5) and you could verify it in your env?

//Magnus

* Magnus Hagander (magnus@hagander.net) wrote:

Ok, I actually have this working now, pending a few cleanups.

Awesome!

Do you have a dev box with 8.3 on it that you could run some tests on? I
could send over a libpq.dll compiled to support both GSSAPI and SSPI (and
krb5) and you could verify it in your env?

Sure, I can get that set up, feel free to email it to me.

Thanks!

Stephen