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.