GSSAPI / SSO java remote EJB client application authentication

[Michael Pritt]

I'm trying to have the wildfly server use SSO using a valid Kerberos ticket that I've already obtained in a remote client application.  The application would pass the kerberos ticket to the server and then access is allowed.  Is there a good example out there that shows how to properly setup the InitialContext and also the proper settings to put in the standalone.xml?   

[Michael Pritt]

I'm not understanding why SSO for wildfly doesn't seem to work, especially when I'm using the same SSO to connect to LDAP.  Both methods are executing within the same Subject privileged action.   Both are using the same Subject (TGT obtained from kerberos), the same mechanism "GSSAPI", and the same settings with the exception of the PROVIDER URL and the INITIAL_CONTEXT_FACTORY.  The WILDFLY attempt fails while the LDAP succeeds.  It looks like they are both sending requests to the same KDC however the response from the KDC when using the WILDFLY context factory is coming back in error.  The exception that I'm getting is:

Suppressed: javax.security.sasl.SaslException: ELY05108: Unable to create response token [Caused by GSSException: No valid credentials provided (Mechanism level: KDC has no support for encryption type (14))]
                        at org.wildfly.security.sasl.gssapi.GssapiClient.evaluateMessage(GssapiClient.java:244)
                        at org.wildfly.security.sasl.util.AbstractSaslParticipant.evaluateMessage(AbstractSaslParticipant.java:225)
                        at org.wildfly.security.sasl.gssapi.GssapiClient.evaluateChallenge(GssapiClient.java:218)
                        at org.wildfly.security.sasl.util.AbstractDelegatingSaslClient.evaluateChallenge(AbstractDelegatingSaslClient.java:54)
                        at org.wildfly.security.sasl.util.PrivilegedSaslClient.lambda$evaluateChallenge$0(PrivilegedSaslClient.java:55)
                        at java.base/java.security.AccessController.doPrivileged(AccessController.java:712)
                        at org.wildfly.security.sasl.util.PrivilegedSaslClient.evaluateChallenge(PrivilegedSaslClient.java:55)
                        at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.lambda$handleEvent$1(ClientConnectionOpenListener.java:459)
                        at org.jboss.remoting3.EndpointImpl$TrackingExecutor.lambda$execute$0(EndpointImpl.java:991)
                        at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
                        at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982)
                        at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
                        at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1348)
                        at org.xnio.XnioWorker$WorkerThreadFactory$1$1.run(XnioWorker.java:1280)
                        at java.base/java.lang.Thread.run(Thread.java:833)
                Caused by: GSSException: No valid credentials provided (Mechanism level: KDC has no support for encryption type (14))
                        at java.security.jgss/sun.security.jgss.krb5.Krb5Context.initSecContext(Krb5Context.java:778)
                        at java.security.jgss/sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:266)
                        at java.security.jgss/sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:196)
                        at org.wildfly.security.sasl.gssapi.GssapiClient.initSecContext(GssapiClient.java:324)
                        at org.wildfly.security.sasl.gssapi.GssapiClient.evaluateMessage(GssapiClient.java:233)
                        ... 14 more
                Caused by: KrbException: KDC has no support for encryption type (14)
                        at java.security.jgss/sun.security.krb5.KrbTgsRep.<init>(KrbTgsRep.java:69)
                        at java.security.jgss/sun.security.krb5.KrbTgsReq.getReply(KrbTgsReq.java:224)
                        at java.security.jgss/sun.security.krb5.KrbTgsReq.sendAndGetCreds(KrbTgsReq.java:235)
                        at java.security.jgss/sun.security.krb5.internal.CredentialsUtil.serviceCredsSingle(CredentialsUtil.java:477)
                        at java.security.jgss/sun.security.krb5.internal.CredentialsUtil.serviceCreds(CredentialsUtil.java:340)
                        at java.security.jgss/sun.security.krb5.internal.CredentialsUtil.serviceCreds(CredentialsUtil.java:314)
                        at java.security.jgss/sun.security.krb5.internal.CredentialsUtil.acquireServiceCreds(CredentialsUtil.java:169)
                        at java.security.jgss/sun.security.krb5.Credentials.acquireServiceCreds(Credentials.java:493)
                        at java.security.jgss/sun.security.jgss.krb5.Krb5Context.initSecContext(Krb5Context.java:700)
                        ... 18 more
                Caused by: KrbException: Identifier doesn't match expected value (906)
                        at java.security.jgss/sun.security.krb5.internal.KDCRep.init(KDCRep.java:140)
                        at java.security.jgss/sun.security.krb5.internal.TGSRep.init(TGSRep.java:65)
                        at java.security.jgss/sun.security.krb5.internal.TGSRep.<init>(TGSRep.java:60)
                        at java.security.jgss/sun.security.krb5.KrbTgsRep.<init>(KrbTgsRep.java:54)
                        ... 26 more

[Michael Pritt]

To further detail this problem, I'm providing the full stack trace (GSSAPI-FullStackTrace.txt), and from that full stacktrace I've further partitioned the WILDFLY attempt (WILDFLY_GSSAPI_STACKTRACE.txt) and the LDAP attempt (LDAP_GSSAPI_STACKTRACE.txt) ... they are both after getting the TGT and operating within the Subject.doAs(lc.getSubject, new PriviledgedExceptionAction<String>(){...}).  I've also further partitioned out the KDC request for each to compare (WILDFLY_GSSAPI_REQ_RESPONSE.txt and LDAP_GSSAPI_REQ_RESPONSE.txt).  I've also provided my code to show the two requests (RemoteClient.java).  Is wildfly code being executed is somehow not encoding correctly the KDC request using a different encryption so that it is not accepted by the KDC?  Am I missing a setting?

[Michael Pritt]

Needed to update here, I realized my issues were with not having the right SPN for my wildfly attempt.