Re: Service principal, GSSAPI and JDBC connection issue

Поиск
Список
Период
Сортировка
От Patrick Radtke
Тема Re: Service principal, GSSAPI and JDBC connection issue
Дата
Msg-id 52A906C1.8030700@stanford.edu
обсуждение исходный текст
Ответ на Service principal, GSSAPI and JDBC connection issue  (Patrick Radtke <pradtke@stanford.edu>)
Список pgsql-jdbc
Is anyone else using GSSAPI authentication?

I would like to submit a patch to fix my problem, but I would like
someone with a different kerberos setup then me to verify it doesn't
cause them issues.

thanks,

Patrick


On 12/6/13, 2:48 PM, Patrick Radtke wrote:
> Hi,
>
> I'm using PostgreSQL 9.1 and I have configured GSSAPI authentication for
> my client application.
>
> The client application has this principal:
> service/uaa-authz-uat01@stanford.edu
>
> and I have it mapped to the DB role/user uaa
>
> pg_ident.conf
> # MAPNAME     SYSTEM-USERNAME                 PG-USERNAME
> krb5          service/uaa-authz-uat01            uaa
>
> Connecting works fine with psql. I use k5start to get the appropriate
> tickets and then connect
>
> k5start -qUf /etc/oauth/keytab -- psql -h authz-uat01 -U uaa
>
> However, when I try connecting with the JDBC driver I run into trouble.
> I've configured my JAAS config
>
> pgjdbc {
>       com.sun.security.auth.module.Krb5LoginModule required
>          principal="service/uaa-authz-uat01"
>          useKeyTab=true
>          keyTab="/etc/oauth/keytab"
>          doNotPrompt=true
>          useTicketCache=true
>          storeKey=true
>          debug=true
>          renewTGT=true;
> };
>
> and my JDBC connection with these properties
> database:
>    driverClassName: org.postgresql.Driver
>    url:
> jdbc:postgresql://authz-uat01.stanford.edu/uaa?ssl=true&sslfactory=org.postgresql.ssl.NonValidatingFactory
>
>    username: uaa
>
>
> however when I go to connect I get the error
> "No valid credentials provided (Mechanism level: Failed to find any
> Kerberos tgt)" which is odd because in the JAAS debug output it seems to
> be able to create a tgt based on the keytab just fine.
>
> Reviewing the code in 'MakeGSS.java' I see the problem.
>
> GSSName clientName = manager.createName(user, GSSName.NT_USER_NAME);
>
> GSSCredential clientCreds = manager.createCredential(clientName, 8*3600,
> desiredMechs, GSSCredential.INITIATE_ONLY);
>
> The driver assumes that the client is a 'GSSName.NT_USER_NAME' which is
> "Name type to indicate a named user on a local system.". It passes in
> 'uaa' (the username) to createName(), and then the next call to
> createCredential() fails since the tgt is for 'service/uaa-authz-uat01'
> and its looking for one that matches 'uaa'.
>
> Setting the db username to 'service/uaa-authz-uat01' gets by the GSSAPI
> issues, but then fails because I don't have (nor wish to have) a
> postgres user with the same name.
>
> Deleting those two lines, and changing the manager.createContext() call to
>
>       GSSContext secContext = manager.createContext(serverName,
> desiredMechs[0], null, GSSContext.DEFAULT_LIFETIME);
>
> e.g. using a null for the 3rd argument
>
> makes the driver work fine.
>
> The javadoc for manager.createContext() says "Use null to act as the
> default initiator principal.".
>
> So...
> does that mean the two lines related clientCreds/Name aren't needed at all?
> If they are needed for some scenarios, how can the code be modified to
> handle both use cases?
>
>
> thanks,
>
> Patrick
>
>
>
>
>
>



В списке pgsql-jdbc по дате отправления:

Предыдущее
От: Patrick Radtke
Дата:
Сообщение: Service principal, GSSAPI and JDBC connection issue
Следующее
От: Charles Pritchard
Дата:
Сообщение: revisiting unix domain sockets