Обсуждение: JDBC and GSSAPI/Krb5 with uDig

Поиск
Список
Период
Сортировка

JDBC and GSSAPI/Krb5 with uDig

От
Stephen Frost
Дата:
Greetings,

  uDig uses JDBC (it actually ships with 8.1-403, technically).  I have
  users who want to use uDig.  We use Kerberos for all of our
  authentication.  I saw that back at the end of January Kris built a
  GSS-enabled version of JDBC and put it up here:

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

  I replaced the 8.1-403 JDBC w/ that one and then followed the
  additional instructions here:

  http://archives.postgresql.org/pgsql-jdbc/2008-01/msg00154.php

  Regarding creating a login.conf, etc.  I've gotten it to the point
  where I can use GSSAPI (requires an 8.3 server, but that's not a huge
  problem) to authenticate from uDig if I provide both a username and a
  password to uDig.  Obviously, that's less than ideal.  This is on a
  Debian system w/ MIT Kerberos and psql and buddies all work fine using
  the existing ticket cache.  Is there something special to get JDBC to
  use the ticket cache in the KRB5CCNAME environment variable?

  Anyone know how this is going to work on a Windows platform?

  I believe the code involved from uDig is this:

http://svn.geotools.org/udig/trunk/plugins/net.refractions.udig.catalog.postgis/src/net/refractions/udig/catalog/internal/postgis/ui/PostGisWizardPage.java

  Is it possible that 'setLogin' is forcing it to try and get a new
  ticket by providing a password?  I couldn't find 'MyGSSTest' in the
  above thread to look at and compare, unfortunately.  A working example
  would be nice, if available.

      Thanks,

        Stephen

Вложения

Re: JDBC and GSSAPI/Krb5 with uDig

От
Kris Jurka
Дата:

On Tue, 6 May 2008, Stephen Frost wrote:

>  Regarding creating a login.conf, etc.  I've gotten it to the point
>  where I can use GSSAPI (requires an 8.3 server, but that's not a huge
>  problem) to authenticate from uDig if I provide both a username and a
>  password to uDig.

You should have only needed a username, not a password.  The previous
version didn't set a default username, so without one it wouldn't know who
to connect to the server as.  The actual authentication should have gone
through without needing the password.

I've put up a new version here that pulls the default username from the
environment.

http://www.ejurka.com/pgsql/jars/gss3/

>  Anyone know how this is going to work on a Windows platform?
>

No idea, I've only been testing on Debian with MIT Kerberos as well.

>  Is it possible that 'setLogin' is forcing it to try and get a new
>  ticket by providing a password?

It's not clear without some further study as this is a couple steps
removed from the JDBC API by some additional factory stuff.

> I couldn't find 'MyGSSTest' in the above thread to look at and compare,
> unfortunately.  A working example would be nice, if available.
>

I've put it up in the same directory as the jar file.

Kris Jurka