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

SPNEGO auth fails if client proposes MS krb5 OID

    XMLWordPrintable

    Details

    • Subcomponent:
    • Introduced In Version:
    • Resolved In Build:
      b64
    • Verification:
      Verified

      Backports

        Description

        FULL PRODUCT VERSION :
        openjdk version "1.8.0_40-"
        OpenJDK Runtime Environment (build 1.8.0_40--vagrant_2015_03_13_10_36-b25)
        OpenJDK 64-Bit Server VM (build 25.40-b25, mixed mode)

        ADDITIONAL OS VERSION INFORMATION :
        Ubuntu 10.04 64-bit

        A DESCRIPTION OF THE PROBLEM :
        I believe I've found a bug in OpenJDK 1.8.0_40, introduced in commit d777e2918a77: http://hg.openjdk.java.net/jdk8u/jdk8u40/jdk/file/d777e2918a77/src/share/classes/sun/security/jgss/spnego/SpNegoContext.java

        The change introduced on line 548 means that an authentication mechanism is only accepted if the OID of the mechanism desired is the first in the list of mechanisms specified as acceptable in the incoming ticket.

        In the case of my current client their service tickets are specifying 4 acceptable mechanism OIDs, but the only available mechanism's OID appears second on that list. So whilst the server can satisfy the ticket, the code change on line 548 prevents this from happening.

        Using the same server code, the same Kerberos KDC, and OpenJDK 1.8.0_31, everything works. Changing only the JDK results in the mechContext not being properly populated, which in turn causes a NullPointerException from some Spring Security Kerberos code.


        REGRESSION. Last worked in version 8u31

        STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
        Provide a Kerberos ticket where the mechanism OID that is supported by the server is _not_ the first listed in the ticket.

        The list of acceptable mechanism OIDs in our ticket was: 1.2.840.48018.1.2.2, 1.2.840.113554.1.2.2, 1.3.6.1.4.1.311.2.2.30, 1.3.6.1.4.1.311.2.2.10

        Our server supported 1.2.840.113554.1.2.2.

        The following code then throws a NullPointer on context.getSrcName(), as the context has not been created.
        GSSContext context = GSSManager.getInstance().createContext((GSSCredential) null);
        byte[] responseToken = context.acceptSecContext(kerberosTicket, 0, kerberosTicket.length);
        String user = context.getSrcName().toString();

        EXPECTED VERSUS ACTUAL BEHAVIOR :
        EXPECTED -
        Executing the following line...

        context.acceptSecContext(kerberosTicket, 0, kerberosTicket.length);

        ... should result in context's mechCtxt being set to a SpNegoContext instance. This in turn has a member mechContext that should be a GSSContextImpl wrapping a Krb5Context.
        ACTUAL -
        SpNegoContext's mechContext member was never populated.

        REPRODUCIBILITY :
        This bug can be reproduced always.

          Attachments

            Issue Links

              Activity

                People

                • Assignee:
                  weijun Weijun Wang
                  Reporter:
                  webbuggrp Webbug Group
                • Votes:
                  0 Vote for this issue
                  Watchers:
                  8 Start watching this issue

                  Dates

                  • Created:
                    Updated:
                    Resolved: