Uploaded image for project: 'WildFly Elytron'
  1. WildFly Elytron
  2. ELY-2314

GSSAPI differences between JAVA implementation and wildfly

XMLWordPrintable

      Wildfly's implementation of GSSAPI is causing errors whereas Java's implementation works.  I'm running into an issue when I attempt to use a kerberos credential using GSSAPI using wildfly's implementation which does not work, and when using that same credential with LDAP using Java's implementation it does work.  It seems that this is caused by difference in the JDK's GSSAPI Sasl implementation and Elytron.  Using the same Subject the LdapCtxFactory has no problems communicating with the KDC, however wildfly's implementation throws errors with that same communication.  It seems that there is a wrong encryption that is happening because the error returned seems to indicate that's the issue. This is the portion of the stack trace...

      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

       

      I've provided the Wildfly request/response to the KDC which throws an error, and also the LDAP request/response which does not.  Both are communicating with the same KDC and using the same Subject and operating in the same security context (i.e. privileged action).  I've also provided the code as well as the full stack trace.

        1. WILDFLY_GSSAPI_REQ_RESPONSE.txt
          22 kB
        2. LDAP_GSSAPI_REQ_RESPONSE.txt
          3 kB
        3. GSSAPI-FullStackTrace.txt
          695 kB
        4. RemoteClient.java
          15 kB
        5. hello-spnego-ejb-elytron.zip
          10 kB
        6. standalone-full-SSL-Example.xml
          38 kB
        7. UsernameClient_STACKTRACE.txt
          405 kB
        8. SpnegoTicket.java
          11 kB

              rhn-support-rmartinc Ricardo Martin Camarero
              michael.pritt@westringtechnologies.com michael pritt (Inactive)
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

                Created:
                Updated:
                Resolved: