Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-6966259

should a principalname object always have a realm?

    XMLWordPrintable

    Details

    • Type: Enhancement
    • Status: Closed
    • Priority: P4
    • Resolution: Fixed
    • Affects Version/s: 7
    • Fix Version/s: 8
    • Component/s: security-libs
    • Labels:
      None
    • Subcomponent:
    • Resolved In Build:
      b49
    • CPU:
      generic
    • OS:
      generic
    • Verification:
      Verified

      Backports

        Description

        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.

          Attachments

            Issue Links

              Activity

                People

                Assignee:
                weijun Weijun Wang
                Reporter:
                weijun Weijun Wang
                Votes:
                0 Vote for this issue
                Watchers:
                1 Start watching this issue

                  Dates

                  Created:
                  Updated:
                  Resolved:
                  Imported:
                  Indexed: