JDK-8043071 : Expose session key and KRB_CRED through extended GSS-API
  • Type: Enhancement
  • Component: security-libs
  • Sub-Component: org.ietf.jgss:krb5
  • Affected Version: 9
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2014-05-14
  • Updated: 2017-05-17
  • Resolved: 2014-07-19
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 9
9 b25Fixed
Related Reports
Duplicate :  
JDK-8049845 - JavaDoc for KerberosKey.getPrincipal does not match the implementation
Relates :  
JDK-8062515 - Migrate use of sun.security.** to supported API
Relates :  
JDK-8170278 - ticket renewal won't happen with debugging turned on
Description
GSS-API is the official API for krb5 in Java but sometimes people needs data that is not available through it. For example, WS-Security needs the context session key to do their own encryption/decryption, one database engine would like to deal with the KRB-CRED token in its own way, and there might be more.
Comments
Currently we are thinking of something like the SASL negotiated property in JAAS, but in an on-demand style. That is to say, a caller can request for a property (using a string key) at an early stage and Java krb5 will provide that property when it's available. There can be two ways: 1. Caller adds a map into private credentials set using property name as key and Java fills the value 2. Caller calls Subject.requestProperty() at an early stage and call Subject.getProperty() later The 1st way needs no new method but the convention should be specified somewhere, therefore equivalent to creating a new API. In either way, it's difficult to precisely specify when the request should be issued and when the result can be retrieved. Maybe we can only say it depends on the actual property. Update: This proposal is discarded mainly because a JAAS subject is able to create multiple GSSContext in different thread at the same time and it's difficult to maintain properties for each of them safely. Back to ExtendedGSSContext.
09-06-2014