[pgjdbc/pgjdbc] PR #3451: Support default GSS credentials in the Java Postgres client

pgjdbc/pgjdbc GitHub issues and pull requests (mirror)  
help / color / mirror / Atom feed

From: nrhall (@nrhall) <[email protected]>
To: pgjdbc/pgjdbc <[email protected]>
Subject: [pgjdbc/pgjdbc] PR #3451: Support default GSS credentials in the Java Postgres client
Date: Thu, 21 Nov 2024 18:14:34 +0000
Message-ID: <[email protected]> (raw)

When using the GSSAPI for authentication without JAAS, the postgres Java client library assumes that the GSS (kerberos) principal name is `$user@$REALM`, and hard-codes the username in the call to `GSSManager.createCredential()` before trying to create the credential.  In most kerberos environments, this is a perfectly reasonable assumption, but it breaks when the user running the process does not have a user formatted in that way.

`GSSManager.createCredential()` has a different overload that doesn't take any hints over the principal to use to create a credential, which instead looks in your Kerberos ccache to see what the default credential is and uses that instead.  This continues to assume that you already have a valid Kerberos ccache (which many corporate environments, such as ours, create automatically for you).

This PR allows the user to provide a new option in the postgres connection properties called `gssUseDefaultCreds` which causes the code to call the no-hint version of `createCredential()` to avoid this particular issue.  I'll note that in most cases, getting the default creds is exactly what you want, and it might even be that a better fix is for this to be the default, but I've not done that here.

A reasonable question at this point is: well, why not use JAAS to do that for you?  The answer is nuanced - if you happen to use a file-based ccache, then you can indeed use JAAS for this.  Unfortunately though, JAAS uses the "pure Java" part of the JGSS codebase which (at least on Linux) does not have a "native" implementation, and is limited in the types of ccache supported.  In particular, it does not support KCM, which is a standard way to use a host-based daemon to store the key material for you.  There are several implementations of KCM (Heimdal Kerberos has one, as do RedHat with SSSD), and using KCM requires the use of the system libraries via the JGSS 'native' implementation, which JAAS does not support.

Thus in addition to avoiding the naming assuming, this PR also allows for the use of existing default credentials via the 'native' JGSS implementation on Linux, and hence supports all ccache types that the system libraries do.

### All Submissions:

* [x] Have you followed the guidelines in our [Contributing](https://github.com/pgjdbc/pgjdbc/blob/master/CONTRIBUTING.md) document?
* [x] Have you checked to ensure there aren't other open [Pull Requests](../../pulls) for the same update/change?

### New Feature Submissions:

1. [x] Does your submission pass tests?  Yes
2. [x] Does `./gradlew styleCheck` pass ?  Yes
3. [x] Have you added your new test classes to an existing test suite in alphabetical order?  (see below re tests)

### Changes to Existing Features:

* [x] Does this break existing behaviour? If so please explain.

No breaks to existing behaviour, as the option defaults to 'false'.  It only changes one piece of code, introducing a conditional to use default GSS credentials instead of assuming that the non-fully qualified principal name is the same as the postgres 'user'.

* [x] Have you added an explanation of what your changes do and why you'd like us to include them?

Documentation updated, motivation above.

* [x] Have you written new tests for your core changes, as applicable?

I'm happy to write tests, but I can't see how the existing GSS code-paths are tested (and I imagine there isn't a sandbox on github where they can be tested).  If you have pointers, please provide and I'll work within that.

* [x] Have you successfully run tests with your changes locally?

Yes - these changes work in our Kerberos environment, where we have a slightly unusual setup where the principals that people use day-to-day are not strictly user-principals (this is perfectly valid, but unusual), and where the 'short' (no realm) principal name is derived from the username, but does not equal it.

Tested on RHEL8.

view thread (15+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: github://pgjdbc/pgjdbc
  Cc: [email protected], [email protected]
  Subject: Re: [pgjdbc/pgjdbc] PR #3451: Support default GSS credentials in the Java Postgres client
  In-Reply-To: <<[email protected]>>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox