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

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

    Details

    • Target Release:
    • Steps to Reproduce:
      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
    • QE Test Coverage:
      +

      Description

      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.

        Gliffy Diagrams

          Attachments

            Issue Links

              Activity

                People

                • Assignee:
                  rhn-support-rmartinc Ricardo Martin Camarero
                  Reporter:
                  spyrkob Bartosz Spyrko
                • Votes:
                  0 Vote for this issue
                  Watchers:
                  1 Start watching this issue

                  Dates

                  • Created:
                    Updated:
                    Resolved: