Uploaded image for project: 'JBoss Enterprise Application Platform'
  1. JBoss Enterprise Application Platform
  2. JBEAP-715

EJB authentication via Kerberos does not work with wildfly-security-api

    XMLWordPrintable

Details

    • Bug
    • Resolution: Done
    • Major
    • 7.0.0.DR11
    • 7.0.0.DR8
    • Security
    • None
    • Hide

      1) Setup server - add KerberosRealm security realm and use it for remoting:
      security realm:

          <security-realm name="KerberosRealm">
        <server-identities>
            <kerberos>
                <keytab principal="remote/localhost@JBOSS.ORG" path="PATH_TO_KEYTAB"/>
            </kerberos>
        </server-identities>
        <authentication>
            <kerberos/>
        </authentication>
    </security-realm>

      use for remoting:

         <http-connector name="http-remoting-connector" connector-ref="default" security-realm="KerberosRealm"/>

      2) Start server and deploy server.jar (see attachements)

      3) Obtain ticket for particular Kerberos user.

      4) Build client project (see attachements) 

      mvn clean package -Dmaven.repo.local=${JBOSS_EAP7.0.0DR8_MAVEN_REPO}

      then run EJB Client via following maven command. EJB invocation will succeed.

      mvn exec:java -Djavax.security.auth.useSubjectCredsOnly=false -Dmaven.repo.local=${JBOSS_EAP7.0.0DR8_MAVEN_REPO}

      5) Uncomment dependency in pom.xml in client project and run EJB Client again by same maven command. EJB invocation will fail.

      Show
      1) Setup server - add KerberosRealm security realm and use it for remoting: security realm: <security-realm name= "KerberosRealm" > <server-identities> <kerberos> <keytab principal= "remote/localhost@JBOSS.ORG" path= "PATH_TO_KEYTAB" /> </kerberos> </server-identities> <authentication> <kerberos/> </authentication> </security-realm> use for remoting: <http-connector name= "http-remoting-connector" connector-ref= "default" security-realm= "KerberosRealm" /> 2) Start server and deploy server.jar (see attachements) 3) Obtain ticket for particular Kerberos user. 4) Build client project (see attachements) mvn clean package -Dmaven.repo.local=${JBOSS_EAP7.0.0DR8_MAVEN_REPO} then run EJB Client via following maven command. EJB invocation will succeed. mvn exec:java -Djavax.security.auth.useSubjectCredsOnly=false -Dmaven.repo.local=${JBOSS_EAP7.0.0DR8_MAVEN_REPO} 5) Uncomment dependency in pom.xml in client project and run EJB Client again by same maven command. EJB invocation will fail.

    Description

      EJB authentication via Kerberos does not work for projects using EJB Client with dependency on org.wildfly:wildfly-security-api. EJB invocation failed with exception:

      java.lang.RuntimeException: javax.security.sasl.SaslException: Authentication failed: all available authentication mechanisms failed:
   GSSAPI: javax.security.sasl.SaslException: ELY05108: [GSSAPI] Unable to create response token [Caused by javax.security.sasl.SaslException: ELY05127: [GSSAPI] No security layer supported by server but maximum message size received: "65536"]
	at org.jboss.ejb.client.remoting.IoFutureHelper.get(IoFutureHelper.java:92)
	at org.jboss.ejb.client.remoting.ConnectionPool.getConnection(ConnectionPool.java:80)
	at org.jboss.ejb.client.remoting.RemotingConnectionManager.getConnection(RemotingConnectionManager.java:51)
	at org.jboss.ejb.client.remoting.ConfigBasedEJBClientContextSelector.setupEJBReceivers(ConfigBasedEJBClientContextSelector.java:158)
	at org.jboss.ejb.client.remoting.ConfigBasedEJBClientContextSelector.getCurrent(ConfigBasedEJBClientContextSelector.java:115)
	at org.jboss.ejb.client.naming.ejb.EjbNamingContext.createIdentifiableEjbClientContext(EjbNamingContext.java:258)
	at org.jboss.ejb.client.naming.ejb.EjbNamingContext.setupScopedEjbClientContextIfNeeded(EjbNamingContext.java:123)
	at org.jboss.ejb.client.naming.ejb.EjbNamingContext.<init>(EjbNamingContext.java:98)
	at org.jboss.ejb.client.naming.ejb.ejbURLContextFactory.getObjectInstance(ejbURLContextFactory.java:38)
	at javax.naming.spi.NamingManager.getURLObject(NamingManager.java:601)
	at javax.naming.spi.NamingManager.getURLContext(NamingManager.java:550)
	at javax.naming.InitialContext.getURLOrDefaultInitCtx(InitialContext.java:345)
	at javax.naming.InitialContext.lookup(InitialContext.java:417)
	at client.Client.main(Client.java:19)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:483)
	at org.codehaus.mojo.exec.ExecJavaMojo$1.run(ExecJavaMojo.java:297)
	at java.lang.Thread.run(Thread.java:745)
Caused by: javax.security.sasl.SaslException: Authentication failed: all available authentication mechanisms failed:
   GSSAPI: javax.security.sasl.SaslException: ELY05108: [GSSAPI] Unable to create response token [Caused by javax.security.sasl.SaslException: ELY05127: [GSSAPI] No security layer supported by server but maximum message size received: "65536"]
	at org.jboss.remoting3.remote.ClientConnectionOpenListener.allMechanismsFailed(ClientConnectionOpenListener.java:114)
	at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:393)
	at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:243)
	at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
	at org.xnio.channels.TranslatingSuspendableChannel.handleReadable(TranslatingSuspendableChannel.java:199)
	at org.xnio.channels.TranslatingSuspendableChannel$1.handleEvent(TranslatingSuspendableChannel.java:113)
	at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
	at org.xnio.ChannelListeners$DelegatingChannelListener.handleEvent(ChannelListeners.java:1092)
	at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
	at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66)
	at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:88)
	at org.xnio.nio.WorkerThread.run(WorkerThread.java:539)
	at ...asynchronous invocation...(Unknown Source)
	at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:272)
	at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:388)
	at org.jboss.ejb.client.remoting.EndpointPool$PooledEndpoint.connect(EndpointPool.java:192)
	at org.jboss.ejb.client.remoting.NetworkUtil.connect(NetworkUtil.java:153)
	at org.jboss.ejb.client.remoting.NetworkUtil.connect(NetworkUtil.java:133)
	at org.jboss.ejb.client.remoting.ConnectionPool.getConnection(ConnectionPool.java:78)
	... 18 more

      Note:
      Dependency org.wildfly:wildfly-security-api has transitive dependency on org.wildfly.security:wildfly-elytron. Artifact wildfly-elytron using service org.wildfly.security.sasl.gssapi.GssapiClientFactory which is added via Java SPI as javax.security.sasl.SaslClientService. Adding this service causes that Kerberos authentication is handled by org.wildfly.security.sasl.gssapi.GssapiClient which leads to authentication failures.

      Attachments

        1. client.zip
          4 kB
        2. server.jar
          3 kB

        Issue Links

          is cloned by

          Bug - A problem that impairs or prevents the functions of the product. ELY-271 EJB authentication via Kerberos does not work with wildfly-security-api

          • Major - To be worked after higher priority work items are addressed. When the severity is high and the effort to change it is low to moderate, this term is chosen. Issues in this category likely have an existing workaround but implementation or execution may be non-trivial.
          • Resolved
          relates to

          Bug - A problem that impairs or prevents the functions of the product. JBEAP-15126 [GSS](7.1.z) org.wildfly.security.sasl.gssapi.GssapiClientFactory on the classpath of jboss-client.jar

          • Major - To be worked after higher priority work items are addressed. When the severity is high and the effort to change it is low to moderate, this term is chosen. Issues in this category likely have an existing workaround but implementation or execution may be non-trivial.
          • Closed

          Activity

            People

              olukas Ondrej Lukas (Inactive)
              olukas Ondrej Lukas (Inactive)
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: