Re: JDBC and GSSAPI/Krb5

Hi all,

I know this question has been asked before, but the answer might have
changed with the impending release of postgresql 8.3. Since 8.3
supports GSSAPI authentication, and Java can talk to Kerberos through
GSSAPI (though not natively), is this feasible? I keep getting this
"authentication type 7 is not supported" errors, so I know it's not
currently supported. Are there any plans to have GSSAPI support for
the 8.3 JDBC driver, or are there showstoppers in doing so?

This would be a very nice selling point and extra feature for
upgrading to 8.3. Thanks much.

Peter

On Wed, 5 Dec 2007, Peter Koczan wrote:

> I know this question has been asked before, but the answer might have
> changed with the impending release of postgresql 8.3. Since 8.3 supports
> GSSAPI authentication, and Java can talk to Kerberos through GSSAPI
> (though not natively), is this feasible? I keep getting this
> "authentication type 7 is not supported" errors, so I know it's not
> currently supported. Are there any plans to have GSSAPI support for the
> 8.3 JDBC driver, or are there showstoppers in doing so?

Henry Hotz, the person who contributed the GSSAPI support for the server,
had plans to do the JDBC work as well, but I haven't seen anything from
him. I've thought about working on it, but since I don't have any
kerberos infrastructure setup, it's kind of a pain to get all that going.
It's unclear how much work it will be, so it might get pushed to the 8.4
driver.

Kris Jurka

OK. I've been warned. ;-)

If I do it over Christmas vacation would that be soon enough?
Unfortunately work commitments have heated up, and I can't really
sneak time for it before then.

On Dec 5, 2007, at 2:01 PM, Kris Jurka wrote:

>
>
> On Wed, 5 Dec 2007, Peter Koczan wrote:
>
>> I know this question has been asked before, but the answer might
>> have changed with the impending release of postgresql 8.3. Since
>> 8.3 supports GSSAPI authentication, and Java can talk to Kerberos
>> through GSSAPI (though not natively), is this feasible? I keep
>> getting this "authentication type 7 is not supported" errors, so I
>> know it's not currently supported. Are there any plans to have
>> GSSAPI support for the 8.3 JDBC driver, or are there showstoppers
>> in doing so?
>
> Henry Hotz, the person who contributed the GSSAPI support for the
> server, had plans to do the JDBC work as well, but I haven't seen
> anything from him. I've thought about working on it, but since I
> don't have any kerberos infrastructure setup, it's kind of a pain
> to get all that going. It's unclear how much work it will be, so it
> might get pushed to the 8.4 driver.
>
> Kris Jurka

------------------------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
Henry(dot)B(dot)Hotz(at)jpl(dot)nasa(dot)gov, or hbhotz(at)oxy(dot)edu

On Wed, 5 Dec 2007, Henry B. Hotz wrote:

> If I do it over Christmas vacation would that be soon enough? Unfortunately
> work commitments have heated up, and I can't really sneak time for it before
> then.
>

That's cutting it real close. The server release is tenatively scheduled
for the first or second week of January and I'll be on vacation the last
two weeks of the year, so it doesn't look good. Unless the changes are
isolated (I'd think so) and trivial (not so sure), it's not going to get
in. I'll see if I can find some time over the next two weeks to work on
it. If not we'll just have to see...

Kris Jurka

On Dec 5, 2007, at 8:37 PM, Kris Jurka wrote:

> On Wed, 5 Dec 2007, Henry B. Hotz wrote:
>
>> If I do it over Christmas vacation would that be soon enough?
>> Unfortunately work commitments have heated up, and I can't really
>> sneak time for it before then.
>>
>
> That's cutting it real close. The server release is tenatively
> scheduled for the first or second week of January and I'll be on
> vacation the last two weeks of the year, so it doesn't look good.
> Unless the changes are isolated (I'd think so) and trivial (not so
> sure), it's not going to get in. I'll see if I can find some time
> over the next two weeks to work on it. If not we'll just have to
> see...
>
> Kris Jurka

Well, maybe I can do a quick feasibility check next week. It might
be easy. I know the Java API is pretty different from C, but I think
not doing security layers localizes what I need to worry about by a lot.

------------------------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
Henry(dot)B(dot)Hotz(at)jpl(dot)nasa(dot)gov, or hbhotz(at)oxy(dot)edu

On Dec 5, 2007 8:59 PM, Henry B. Hotz <hotz(at)jpl(dot)nasa(dot)gov> wrote:
> OK. I've been warned. ;-)
>
> If I do it over Christmas vacation would that be soon enough?
> Unfortunately work commitments have heated up, and I can't really
> sneak time for it before then.

FWIW, I'd be willing to be a tester for this and run this even as a
beta version.

Peter

Thank you. I'm looking at it.

I think the changes *should* be localized to v3/
ConnectionFactoryImpl.java. I need to see how Magnus changed the
wire protocol (he did it differently from what I did), and I need to
try a sample program first so I can debug wire/API issues
independently from PG issues.

I will not even attempt to address the SSPI auth mechanism since I
don't understand fully why it exists. SSPI is supposed to just be an
alternate C binding for the GSSAPI wire protocol, but there are other
issues that confound that statement. I believe that Java should
stick to the standard, at least initially.

On Dec 6, 2007, at 8:13 AM, Peter Koczan wrote:

> On Dec 5, 2007 8:59 PM, Henry B. Hotz <hotz(at)jpl(dot)nasa(dot)gov> wrote:
>> OK. I've been warned. ;-)
>>
>> If I do it over Christmas vacation would that be soon enough?
>> Unfortunately work commitments have heated up, and I can't really
>> sneak time for it before then.
>
> FWIW, I'd be willing to be a tester for this and run this even as a
> beta version.
>
> Peter

On Dec 6, 2007 1:10 PM, Henry B. Hotz <hotz(at)jpl(dot)nasa(dot)gov> wrote:
> Thank you. I'm looking at it.
>
> I think the changes *should* be localized to v3/
> ConnectionFactoryImpl.java. I need to see how Magnus changed the
> wire protocol (he did it differently from what I did), and I need to
> try a sample program first so I can debug wire/API issues
> independently from PG issues.
>
> I will not even attempt to address the SSPI auth mechanism since I
> don't understand fully why it exists. SSPI is supposed to just be an
> alternate C binding for the GSSAPI wire protocol, but there are other
> issues that confound that statement. I believe that Java should
> stick to the standard, at least initially.

http://people.planetpostgresql.org/mha/index.php?/archives/155-Integrated-Security-in-PostgreSQL-8.3.html

According to this, SSPI is a Windows-only thing (for both clients and
servers). Apparently each can authenticate against a "gss" entry in
pg_hba.conf.

I don't know what implications that has for support in the JDBC
driver. I'll let you figure that out :-).

Peter

On Dec 6, 2007 1:47 PM, Peter Koczan <pjkoczan(at)gmail(dot)com> wrote:
> On Dec 6, 2007 1:10 PM, Henry B. Hotz <hotz(at)jpl(dot)nasa(dot)gov> wrote:
> > Thank you. I'm looking at it.
> >
> > I think the changes *should* be localized to v3/
> > ConnectionFactoryImpl.java. I need to see how Magnus changed the
> > wire protocol (he did it differently from what I did), and I need to
> > try a sample program first so I can debug wire/API issues
> > independently from PG issues.
> >
> > I will not even attempt to address the SSPI auth mechanism since I
> > don't understand fully why it exists. SSPI is supposed to just be an
> > alternate C binding for the GSSAPI wire protocol, but there are other
> > issues that confound that statement. I believe that Java should
> > stick to the standard, at least initially.
>
> http://people.planetpostgresql.org/mha/index.php?/archives/155-Integrated-Security-in-PostgreSQL-8.3.html
>
> According to this, SSPI is a Windows-only thing (for both clients and
> servers). Apparently each can authenticate against a "gss" entry in
> pg_hba.conf.
>
> I don't know what implications that has for support in the JDBC
> driver. I'll let you figure that out :-).

Oh, and by "each" I mean both SSPI and GSSAPI.

B'oh.

Peter

On Dec 6, 2007, at 11:47 AM, Peter Koczan wrote:

> On Dec 6, 2007 1:10 PM, Henry B. Hotz <hotz(at)jpl(dot)nasa(dot)gov> wrote:
>> Thank you. I'm looking at it.
>>
>> I think the changes *should* be localized to v3/
>> ConnectionFactoryImpl.java. I need to see how Magnus changed the
>> wire protocol (he did it differently from what I did), and I need to
>> try a sample program first so I can debug wire/API issues
>> independently from PG issues.
>>
>> I will not even attempt to address the SSPI auth mechanism since I
>> don't understand fully why it exists. SSPI is supposed to just be an
>> alternate C binding for the GSSAPI wire protocol, but there are other
>> issues that confound that statement. I believe that Java should
>> stick to the standard, at least initially.
>
> http://people.planetpostgresql.org/mha/index.php?/archives/155-
> Integrated-Security-in-PostgreSQL-8.3.html
>
> According to this, SSPI is a Windows-only thing (for both clients and
> servers). Apparently each can authenticate against a "gss" entry in
> pg_hba.conf.
>
> I don't know what implications that has for support in the JDBC
> driver. I'll let you figure that out :-).
>
> Peter

What he says about not verifying the domain is a serious security bug
IMO, but it's been discussed. I think it's a little more complex
than that posting indicates.

If they are wire-compatible then there is no reason to use a
different value on the wire to differentiate them. This is the point
that I said I didn't understand.

This is the wrong audience for these complaints though.

------------------------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
Henry(dot)B(dot)Hotz(at)jpl(dot)nasa(dot)gov, or hbhotz(at)oxy(dot)edu

On Thu, 6 Dec 2007, Henry B. Hotz wrote:

> If they are wire-compatible then there is no reason to use a different value
> on the wire to differentiate them. This is the point that I said I didn't
> understand.
>

I think the point is that a client using the SSPI library can operate
wire-compatibly with a server using the GSSSPI library, but that only
happens with the auth type of "gss". When the "sspi" auth type is used,
that signals to a client using the SSPI library to do something
non wire-compatible and that's why the two auth types are used.

Kris Jurka

On Dec 6, 2007, at 12:05 PM, Kris Jurka wrote:

>
>
> On Thu, 6 Dec 2007, Henry B. Hotz wrote:
>
>> If they are wire-compatible then there is no reason to use a
>> different value on the wire to differentiate them. This is the
>> point that I said I didn't understand.
>>
>
> I think the point is that a client using the SSPI library can
> operate wire-compatibly with a server using the GSSSPI library, but
> that only happens with the auth type of "gss". When the "sspi"
> auth type is used, that signals to a client using the SSPI library
> to do something non wire-compatible and that's why the two auth
> types are used.
>
> Kris Jurka

I'm not enough of a Windows person to know if that makes sense. I'll
ask Magnus when I get far enough it matters. I think my choices are
to ignore the difference or to only support the two GSS types.

------------------------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
Henry(dot)B(dot)Hotz(at)jpl(dot)nasa(dot)gov, or hbhotz(at)oxy(dot)edu

> I'm not enough of a Windows person to know if that makes sense. I'll
> ask Magnus when I get far enough it matters. I think my choices are
> to ignore the difference or to only support the two GSS types.

Hello again, has there been progress on this? As I said before I'm
willing to be a beta tester for this.

Peter

On Thu, 24 Jan 2008, Peter Koczan wrote:

> Hello again, has there been progress on this? As I said before I'm
> willing to be a beta tester for this.
>

I've hacked together a prototype and can successfully authenticate against
a gssapi configured server. It needs a fair amount of cleanup, but there
are some more fundamental questions about what configuration options we
need:

1) Do we need a way for the user to uniquely name the application for the
JAAS LoginContext or can we get away with something generic like pgjdbc?
The application name is needed for the JAAS login configuration file which
is needed to enable the krb5 ticket cache. I'm not sure what else would
need to be configured or why you might want to do it differently for
different applications.

2) Do we need to allow the user to configure their own LoginContext
CallbackHandler to enter a username/password if they don't have an
existing entry in their ticket cache? Should we by default just try to
use the username and password provided in the connection parameters?

3) Do we need a way for the user to specify the server's service name
(what libpq calls PGKRBSRVNAME)? I think this is useful if you're running
two pg servers on the same machine and want to have different rules for
each one, but I'm not entirely sure about that.

Kris Jurka

On Jan 28, 2008, at 2:32 AM, Kris Jurka wrote:

> On Thu, 24 Jan 2008, Peter Koczan wrote:
>
>> Hello again, has there been progress on this? As I said before I'm
>> willing to be a beta tester for this.

As would I. I have fewer bureaucratic restrictions on fixing bugs
than I do on delivering code for new capabilities.

> I've hacked together a prototype and can successfully authenticate
> against a gssapi configured server. It needs a fair amount of
> cleanup, but there are some more fundamental questions about what
> configuration options we need:
>
> 1) Do we need a way for the user to uniquely name the application
> for the JAAS LoginContext or can we get away with something generic
> like pgjdbc? The application name is needed for the JAAS login
> configuration file which is needed to enable the krb5 ticket
> cache. I'm not sure what else would need to be configured or why
> you might want to do it differently for different applications.

I bow to people with more Java experience on this, but I will make
two observations:

1) I've run into a lot of example code that will not properly fall
back to system defaults when the defaults in the JAAS config file are
omitted.

2) I expect a number of users to want to run different applications
which in turn connect to different databases. It's desirable that
the user not need to change their configuration files in order to
change applications/databases, particularly if they run in the same
Kerberos realm (or cross-realm trust network).

> 2) Do we need to allow the user to configure their own LoginContext
> CallbackHandler to enter a username/password if they don't have an
> existing entry in their ticket cache? Should we by default just
> try to use the username and password provided in the connection
> parameters?

In practice you may run a Java program on a Windows machine which has
its own (AD based) idea of what the Kerberos configuration and
tickets are supposed to be. Imagine a database hosted in one Windows
Domain, but being run from a workstation joined to a different one
with no cross-realm trust. (You can have the same problem with non-
Windows machines, but they have non-obscure ways of getting tickets
from foreign realms, so it's not as big a deal.)

> 3) Do we need a way for the user to specify the server's service
> name (what libpq calls PGKRBSRVNAME)? I think this is useful if
> you're running two pg servers on the same machine and want to have
> different rules for each one, but I'm not entirely sure about that.

I think so, and it ought to default to the same value that configure
defaults to on the server side.

> Kris Jurka

------------------------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
Henry(dot)B(dot)Hotz(at)jpl(dot)nasa(dot)gov, or hbhotz(at)oxy(dot)edu

On Mon, 28 Jan 2008, Henry B. Hotz wrote:

>
> On Jan 28, 2008, at 2:32 AM, Kris Jurka wrote:
>
>> I've hacked together a prototype and can successfully authenticate against
>> a gssapi configured server. It needs a fair amount of cleanup, but there
>> are some more fundamental questions about what configuration options we
>> need:

I've put up the current patch and a test jar file at:

http://ejurka.com/pgsql/jars/gss

At the moment it doesn't offer any of the configurability previously
discussed except for the fact that it will use the password supplied in
the connection request to try to acquire a ticket if none is cached.

The application name for the JAAS LoginContext is "pgjdbc".

It only support V3 protocol connections (default for 7.4+ servers). Let
me know how it works and what else you would need for production use.

Kris Jurka

> I've put up the current patch and a test jar file at:
>
> http://ejurka.com/pgsql/jars/gss
>
> At the moment it doesn't offer any of the configurability previously
> discussed except for the fact that it will use the password supplied in
> the connection request to try to acquire a ticket if none is cached.
>
> The application name for the JAAS LoginContext is "pgjdbc".
>
> It only support V3 protocol connections (default for 7.4+ servers). Let
> me know how it works and what else you would need for production use.

Where I work, we can use a simple connection string, devoid of any
user or password information, to connect via psql or DBD::Pg, and
Kerberos works its magic to authenticate to the database server
properly. I wouldn't mind telling people that they need to specify a
username with JDBC, but this behavior would mimic that of other
Kerberos/GSSAPI-enabled interfaces. It's possibly something to keep in
mind, but if it's too much work or not very feasible or
non-JDBC-compliant, I wouldn't worry about it.

However, I'm having a bit of trouble authenticating with a simple
program (see below). Granted, I'm still a bit new to JDBC, so please
point out any stupid mistakes, maybe I forgot a config step. I did
follow the docs, but no combination of username/password would work,
not even my true Kerberos password. (I can still connect via an
MD5-based user account).

The file:

import java.sql.*; // import the JDBC
import java.util.*;

public class Jdbc {
public static void main (String[] args) {
try {
Class.forName("org.postgresql.Driver"); // Load the PostgreSQL JDBC driv
er

// Connect to the database
Properties props = new Properties();
props.setProperty("user", "koczan");
props.setProperty("password", "[password]");
// props.setProperty("ssl", "true"); // I'll get this working later
Connection conn =
DriverManager.getConnection("jdbc:postgresql://mitchell.cs.wisc.edu:5434/postgres",
props);

Statement st = conn.createStatement();
ResultSet rs = st.executeQuery("select datname from
pg_database order by 1");
while (rs.next()) {
System.out.print("Database name returned: ");
System.out.println(rs.getString(1));
}
rs.close();
st.close();

} catch (Throwable ex) {
System.err.println("Uncaught exception in main...");
ex.printStackTrace();
}
}
}

The output was:
$ export CLASSPATH=/s/postgresql-8.3-beta/src/postgresql-jdbc-8.3dev-601.src/jars/postgresql-8.3dev-gss.jdbc3g.jar
$ javac Jdbc.Java
$ java Jdbc
Uncaught exception in main...
org.postgresql.util.PSQLException: GSS Authentication failed
at org.postgresql.gss.MakeGSS.authenticate(MakeGSS.java:36)
at org.postgresql.Driver.makeGSS(Driver.java:775)
at org.postgresql.core.v3.ConnectionFactoryImpl.doAuthentication(ConnectionFactoryImpl.java:373)
at org.postgresql.core.v3.ConnectionFactoryImpl.openConnectionImpl(ConnectionFactoryImpl.java:98)
at org.postgresql.core.ConnectionFactory.openConnection(ConnectionFactory.java:66)
at org.postgresql.jdbc2.AbstractJdbc2Connection.<init>(AbstractJdbc2Connection.java:124)
at org.postgresql.jdbc3.AbstractJdbc3Connection.<init>(AbstractJdbc3Connection.java:30)
at org.postgresql.jdbc3g.Jdbc3gConnection.<init>(Jdbc3gConnection.java:24)
at org.postgresql.Driver.makeConnection(Driver.java:386)
at org.postgresql.Driver.connect(Driver.java:260)
at java.sql.DriverManager.getConnection(DriverManager.java:525)
at java.sql.DriverManager.getConnection(DriverManager.java:140)
at Jdbc.main(Jdbc.java:16)
Caused by: java.lang.SecurityException: Unable to locate a login configuration
at com.sun.security.auth.login.ConfigFile.<init>(ConfigFile.java:97)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:494)
at java.lang.Class.newInstance0(Class.java:350)
at java.lang.Class.newInstance(Class.java:303)
at javax.security.auth.login.Configuration$3.run(Configuration.java:216)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.login.Configuration.getConfiguration(Configuration.java:210)
at javax.security.auth.login.LoginContext$1.run(LoginContext.java:237)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.login.LoginContext.init(LoginContext.java:234)
at javax.security.auth.login.LoginContext.<init>(LoginContext.java:403)
at org.postgresql.gss.MakeGSS.authenticate(MakeGSS.java:29)
... 12 more
Caused by: java.io.IOException: Unable to locate a login configuration
at com.sun.security.auth.login.ConfigFile.init(ConfigFile.java:206)
at com.sun.security.auth.login.ConfigFile.<init>(ConfigFile.java:95)
... 26 more

I expected:

$ java Jdbc
Database name returned: postgres
Database name returned: template0
Database name returned: template1

On Tue, 29 Jan 2008, Peter Koczan wrote:

> Where I work, we can use a simple connection string, devoid of any
> user or password information, to connect via psql or DBD::Pg, and
> Kerberos works its magic to authenticate to the database server
> properly. I wouldn't mind telling people that they need to specify a
> username with JDBC, but this behavior would mimic that of other
> Kerberos/GSSAPI-enabled interfaces. It's possibly something to keep in
> mind, but if it's too much work or not very feasible or
> non-JDBC-compliant, I wouldn't worry about it.

I'll look into that.

> However, I'm having a bit of trouble authenticating with a simple
> program (see below).
>
> Caused by: java.lang.SecurityException: Unable to locate a login configuration
>

The problem is that even though we know we're using GSSAPI backed by
Kerberos, Java has a generic authentication mechanism that I didn't see a
way to avoid going through and you've got to configure this generic
mechanism to tell it you want to use Kerberos. I've been doing my testing
via:

java -Djava.security.auth.login.config=login.conf MyGssTest

where login.conf contains:

pgjdbc {
com.sun.security.auth.module.Krb5LoginModule required useTicketCache=true;
};

There are other ways of configuring the login module other than specifying
it on the command line:

http://java.sun.com/j2se/1.4.2/docs/guide/security/jaas/tutorials/LoginConfigFile.html

Additionally there is a means of providing this configuration in code form
(which I've yet to test), but that only works on 1.5+ while GSSAPI works
on 1.4 as well. Further as you can tell from the above configuration,
it's specific to the JVM you're running on. You wouldn't use com.sun.* on
a non-Sun JVM. Finally people may want different options enabled in the
config, so hardcoding this doesn't work from that perspective either:

http://java.sun.com/j2se/1.4.2/docs/guide/security/jaas/spec/com/sun/security/auth/module/Krb5LoginModule.html

So perhaps there are better ways of doing things, but I've never used
these APIs before this effort, so I'm certainly no expert. Henry sounds
like he has some more experience in this area, so hopefully he'll weigh
in.

In any case there are enough outstanding issues with the need for
additional configurability that this will not go into the 8.3 release
(which needs to go out this week).

Kris Jurka

On Jan 30, 2008, at 12:59 AM, Kris Jurka wrote:

> Additionally there is a means of providing this configuration in
> code form (which I've yet to test), but that only works on 1.5+
> while GSSAPI works on 1.4 as well. Further as you can tell from
> the above configuration, it's specific to the JVM you're running
> on. You wouldn't use com.sun.* on a non-Sun JVM. Finally people
> may want different options enabled in the config, so hardcoding
> this doesn't work from that perspective either:

I wouldn't worry toooo much about 1.4. It has a lot of issues,
including only supporting single DES encryption types. The only
"current" platform I deal with that uses 1.4 is Solaris 9, and it's
pretty easy to provide a newer JVM on a Sun.

Ideally the code should provide reasonable (overwriteable) defaults
wherever possible.

More later.
------------------------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
Henry(dot)B(dot)Hotz(at)jpl(dot)nasa(dot)gov, or hbhotz(at)oxy(dot)edu