RFR: 8349546: Linux support for Kerberos "nativeccache" functionality [v12]

[Nick Hall]

On Thu, 13 Nov 2025 11:09:49 GMT, Bernd <duke at openjdk.org> wrote:

> Thanks for the work and maybe sorry for a dumb question but maybe it helps with documentation - if i get this right this only works for cases where the native client actually can extract the key credentials but not for things where a external component would be needed to apply them (like ssdp, tpm, sssd and the like, right?)

Assuming I've understood your question:
- this works for all cases where the system libraries could get to a TGT in a ccache - so FILE:, MEMORY:, KEYRING:, KCM:, etc.  For things like `sssd`, assuming that's using the `sssd` KCM implementation, that should work (we use KCM here, though not `sssd`'s implementation).
- If something else is needed to extract/convert a secret that's stored in another place and use it as a key to get a TGT from the KDC, this wouldn't help, although as you can hopefully see from the test helper, once you've got the TGT in Java, it wouldn't be that hard to have a set of JNI helper functions so that it could be _written_ to the right ccache type (as opposed to now, when this would have to be a FILE: ccache).  My reading of the way this works in JAAS currently though is that any acquired key/keytab etc is only written to the private credentials in the `javax.security.auth.Subject` object, and never actually written back to the ccache.

Was that what you were getting at?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28075#issuecomment-3527396396