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.