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

[GSS] (7.2.z) WFCORE-4803 - EJB Client authentication does not work using SASL DIGEST-MD5 and EXTERNAL mechanisms in Legacy security

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Done
    • Icon: Major Major
    • 7.2.8.CR1, 7.2.8.GA
    • 7.2.5.GA
    • EJB, Security
    • None
    • +
    • Hide

      This is an EJB over SSL. To test you should create a certificate and configure it in EAP. After that, these are the steps to test:

      1. Deploy the sampleejboverssl
      2. Use the sampleejbclientoverssl to call the remote EJB (sampleejboverssl). You should run passing the -Djavax.net.ssl.trustStore properties with the certificate configured.
      3. Configure the remoting subsytems according to standalone.xml attached.

      I have attached a standalone.xml that is the configuration used in my local environment

      Show
      This is an EJB over SSL. To test you should create a certificate and configure it in EAP. After that, these are the steps to test: Deploy the sampleejboverssl Use the sampleejbclientoverssl to call the remote EJB (sampleejboverssl). You should run passing the -Djavax.net.ssl.trustStore properties with the certificate configured. Configure the remoting subsytems according to standalone.xml attached. I have attached a standalone.xml that is the configuration used in my local environment

      The application does not working when use the DIGEST-MD5 mechanism in the legacy security. This this the configuration on standalone.xml:

      <subsystem xmlns="urn:jboss:domain:remoting:4.0">
                  <http-connector name="http-remoting-connector" connector-ref="https" security-realm="ApplicationRealm">
                      <sasl>
                          <include-mechanisms value="DIGEST-MD5"/>
                          <qop value="auth"/>
                          <strength value="medium"/>
                          <server-auth value="false"/>
                          <reuse-session value="false"/>
                          <policy>
                              <forward-secrecy value="true"/>
                              <no-active value="false"/>
                              <no-anonymous value="false"/>
                              <no-dictionary value="true"/>
                              <no-plain-text value="false"/>
                              <pass-credentials value="true"/>
                          </policy>
                      </sasl>
                  </http-connector>
              </subsystem>
      

      Using this configuration I have seen this exception in the application:

      019-12-16 09:08:44,132 TRACE [org.wildfly.security] (default task-1) Handling RealmCallback: selected = [RemotingRealm]
      2019-12-16 09:08:44,132 TRACE [org.wildfly.security] (default task-1) Handling NameCallback: authenticationName = stubejbclient
      2019-12-16 09:08:44,133 TRACE [org.wildfly.security] (default task-1) Principal assigning: [stubejbclient], pre-realm rewritten: [stubejbclient@RemotingRealm], realm name: [DIGEST-MD5], post-realm rewritten: [stubejbclient@RemotingRealm], realm rewritten: [stubejbclient@RemotingRealm]
      2019-12-16 09:08:44,133 TRACE [org.wildfly.security] (default task-1) Handling CredentialCallback: failed to obtain credential
      2019-12-16 09:08:44,133 TRACE [org.wildfly.security] (default task-1) Handling RealmCallback: selected = [RemotingRealm]
      2019-12-16 09:08:44,133 TRACE [org.wildfly.security] (default task-1) Handling NameCallback: authenticationName = stubejbclient
      2019-12-16 09:08:44,133 TRACE [org.wildfly.security] (default task-1) Handling CredentialCallback: failed to obtain credential
      2019-12-16 09:08:44,133 TRACE [org.wildfly.security] (default task-1) Handling RealmCallback: selected = [RemotingRealm]
      2019-12-16 09:08:44,133 TRACE [org.wildfly.security] (default task-1) Handling NameCallback: authenticationName = stubejbclient
      2019-12-16 09:08:44,133 TRACE [org.wildfly.security] (default task-1) Handling PasswordCallback: PasswordCredential may not be supported
      2019-12-16 09:08:44,133 TRACE [org.jboss.remoting.remote.server] (default task-1) Server sending authentication rejected: javax.security.sasl.SaslException: ELY05051: Callback handler does not support credential acquisition [Caused by org.wildfly.security.auth.callback.FastUnsupportedCallbackException: javax.security.auth.callback.PasswordCallback@1cf94092]
              at org.wildfly.security.mechanism.digest.PasswordDigestObtainer.getSaltedPasswordFromPasswordCallback(PasswordDigestObtainer.java:295)
              at org.wildfly.security.mechanism.digest.PasswordDigestObtainer.handleUserRealmPasswordCallbacks(PasswordDigestObtainer.java:112)
              at org.wildfly.security.sasl.digest.AbstractDigestMechanism.handleUserRealmPasswordCallbacks(AbstractDigestMechanism.java:195)
              at org.wildfly.security.sasl.digest.DigestSaslServer.validateDigestResponse(DigestSaslServer.java:264)
              at org.wildfly.security.sasl.digest.DigestSaslServer.evaluateMessage(DigestSaslServer.java:363)
              at org.wildfly.security.sasl.util.AbstractSaslParticipant.evaluateMessage(AbstractSaslParticipant.java:199)
              at org.wildfly.security.sasl.digest.DigestSaslServer.evaluateResponse(DigestSaslServer.java:336)
              at org.wildfly.security.sasl.util.AuthenticationCompleteCallbackSaslServerFactory$1.evaluateResponse(AuthenticationCompleteCallbackSaslServerFactory.java:58)
              at org.wildfly.security.sasl.util.AuthenticationTimeoutSaslServerFactory$DelegatingTimeoutSaslServer.evaluateResponse(AuthenticationTimeoutSaslServerFactory.java:106)
              at org.wildfly.security.sasl.util.SecurityIdentitySaslServerFactory$1.evaluateResponse(SecurityIdentitySaslServerFactory.java:59)
              at org.xnio.sasl.SaslUtils.evaluateResponse(SaslUtils.java:245)
              at org.xnio.sasl.SaslUtils.evaluateResponse(SaslUtils.java:217)
              at org.jboss.remoting3.remote.ServerConnectionOpenListener$AuthStepRunnable.run(ServerConnectionOpenListener.java:486)
              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:1985)
              at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
              at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378)
              at java.lang.Thread.run(Thread.java:748)
      Caused by: org.wildfly.security.auth.callback.FastUnsupportedCallbackException: javax.security.auth.callback.PasswordCallback@1cf94092
      
      2019-12-16 09:08:44,133 TRACE [org.wildfly.security] (default task-1) Handling AuthenticationCompleteCallback: fail
      2019-12-16 09:08:44,133 TRACE [org.jboss.remoting.remote.server] (default task-1) No more authentication attempts allowed, closing the connection
      

      It works to EAP 7.0.x but is not working to EAP 7.2.x.

      The same configuration works on JBoss EAP 7.0.z. I'm attaching the EJB client, EJB service and standalone.xm.

        1. standalone.xml
          28 kB
        2. sampleejboverssl.zip
          40 kB
        3. sampleejbclientoverssl.zip
          23 kB

              rhn-support-rmartinc Ricardo Martin Camarero
              rhn-support-rhsilva Rhuan Rocha (Inactive)
              Votes:
              0 Vote for this issue
              Watchers:
              9 Start watching this issue

                Created:
                Updated:
                Resolved: