-
Enhancement
-
Resolution: Fixed
-
P4
-
7
-
None
-
b49
-
generic
-
generic
-
Verified
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-8141310 | openjdk7u | Weijun Wang | P4 | Resolved | Fixed | master |
When a PrincipalName is created, if there's no "@xxx" section in the name, the default realm defined in krb5.conf is used. Therefore, a PrincipalName created from a string name always has a realm. On the other hand, a PrincipalName created from a DER encoding never has a realm, and no default value is assigned.
Then, in multiple places of JDK, checking on if the realm is null is performed. Obviously this is not about checking if the object is built from DER encoding or strings. For example, in Kinit and TGS-REQ, the client name and service name, respectively, are created from strings, but in both places realm==null is checked. This is useless.
The conclusion is that Realm in PrincipalName is not implemented consistently, or, the design of putting realm info inside principal name is not correct. In the krb5 spec, PrincpalName and Realm are two different data type with no overlapping info.
We should either pull Realm out of PrincipalName, or concrete it when a PrincipalName is created. In either way, both classes should be immutable and all fields final and non-null non-empty.
Then, in multiple places of JDK, checking on if the realm is null is performed. Obviously this is not about checking if the object is built from DER encoding or strings. For example, in Kinit and TGS-REQ, the client name and service name, respectively, are created from strings, but in both places realm==null is checked. This is useless.
The conclusion is that Realm in PrincipalName is not implemented consistently, or, the design of putting realm info inside principal name is not correct. In the krb5 spec, PrincpalName and Realm are two different data type with no overlapping info.
We should either pull Realm out of PrincipalName, or concrete it when a PrincipalName is created. In either way, both classes should be immutable and all fields final and non-null non-empty.
- backported by
-
JDK-8141310 should a principalname object always have a realm?
-
- Resolved
-
- relates to
-
JDK-6355584 introduce constrained Kerberos delegation
-
- Closed
-