Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The scenario where this is useful: we have users who use the OS-native Kerberos support to obtain a Kerberos ticket-granting ticket when they start using their workstation. The Kerberos TGT is stored in the OS-native credential cache (e.g. an API: cache on Mac OS X, or a FILE: or KEYRING: cache on Linux). They later want to use a SQL client application (e.g SQL Workbench/J) that uses this JDBC driver to talk to PostgreSQL, using GSS authentication with their existing Kerberos ticket.
Unfortunately there is no support in Oracle's Krb5LoginModule for reading Kerberos tickets out of API: or KEYRING: credential caches, it only supports file ccaches, so the usage of Krb5LoginModule to try and obtain Kerberos credentials throws an exception.
However, there is support in Oracle JDK 8 for using the native GSS-API implementation on Linux, Solaris and OS X by setting the system property “sun.security.jgss.native” to true. That allows JGSS to use existing tickets stored in native credential caches, so no JAAS login is required. If we skip trying to read the ticket using Krb5LoginModule, and rely on the native implementation, users can authenticate to PostgreSQL using their existing native ticket, without an extra prompt for a password.
The default for this new option is true, i.e. do attempt JAAS login (unless the Subject already has GSS credentials), which is the same as the current behaviour. The option must explicitly be set to false to disable JAAS login.