Uploaded image for project: 'WildFly'
  1. WildFly
  2. WFLY-19571

JNDI lookup with SSL/Authentication: Client freeze

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Major Major
    • None
    • 31.0.1.Final
    • Remoting
    • None
    • Hide
      1. Unzip attached Maven Project 'wildfly-jndi-tester'.
      2. Copy contained 'standalone.xml' ('res' folder) to the Wildfly instance (I used version 31.0.1 Final).
      3. Copy contained 'appliation.keystore' and 'client.truststore.jks' ('res' folder) to path 'D:/_temp' (if other path if used, line 44 of 'COMTestService.java' and line 360 of 'standalone.xml' must be adapted!)
      4. Deploy 'wildfly-jndi-tester-1.0.0.jar' to the Wildfly instance and start Wildfly
      5. Run the class 'gui.TestingGui' and click on the button -> SaslException is thrown (OK so far).
      6. Close the GUI and run 'gui.TestingGui' again, click the button again -> Client freeze! nOK!

      Unlike the attached Maven project, the client in our enterprise application gets stuck even on the first try (not the second), but I assume the cause is the same.

      Show
      Unzip attached Maven Project 'wildfly-jndi-tester'. Copy contained 'standalone.xml' ('res' folder) to the Wildfly instance (I used version 31.0.1 Final). Copy contained 'appliation.keystore' and 'client.truststore.jks' ('res' folder) to path 'D:/_temp' (if other path if used, line 44 of 'COMTestService.java' and line 360 of 'standalone.xml' must be adapted!) Deploy 'wildfly-jndi-tester-1.0.0.jar' to the Wildfly instance and start Wildfly Run the class 'gui.TestingGui' and click on the button -> SaslException is thrown (OK so far). Close the GUI and run 'gui.TestingGui' again , click the button again -> Client freeze! nOK! Unlike the attached Maven project, the client in our enterprise application gets stuck even on the first try (not the second), but I assume the cause is the same.
    • Migration
    • Workaround Exists
    • Hide

      As a workaround we figured out that if we do the JNDI lookup with definitely correct credentials of a technical user first and then try again with the real user credentials second,  the client doesn't get stuck even if the user credentials are wrong.

      Show
      As a workaround we figured out that if we do the JNDI lookup with definitely correct credentials of a technical user first and then try again with the real user credentials second,  the client doesn't get stuck even if the user credentials are wrong.
    • ---
    • ---

      In our enterprise application we have a problem with the JNDI lookup of a secured EJB that causes the client to freeze if credentials are wrong.

      If the JNDI lookup is performed with incorrect credentials, we usually get following exception on client side:

      javax.naming.CommunicationException: WFNAM00018: Failed to connect to remote host [Root exception is javax.security.sasl.SaslException: Authentication failed: all available authentication mechanisms failed:
   PLAIN: javax.security.sasl.SaslException: PLAIN: Server rejected authentication]
    at org.wildfly.naming.client.remote.RemoteNamingProvider.getPeerIdentityForNaming(RemoteNamingProvider.java:110)
    at org.wildfly.naming.client.remote.RemoteNamingProvider.getPeerIdentityForNaming(RemoteNamingProvider.java:53)
    ...

      -> This is the expected behavior.

      But in our constellation (SSL communication + jdbc-realm (-> see standalone.xml), Wildfly 31), there's no exception, just a freeze on the client side.

      The problem seems to be related to 'JBoss Remoting version 5.0.28.Final':
      If we use a version below 30 for dependency 'wildfly-client-all' in the pom.xml of attached mavend project, everythings works as expected -> we get a SaslException each try and the client doesn't get stuck (in this case it shows 'JBoss Remoting version 5.0.27.Final'). If we use version 30 or higher ('JBoss Remoting version 5.0.28.Final'), we observe the above described issue.

              flaviarnn Flavia Rainone
              pascal.kirchner Pascal Kirchner (Inactive)
              Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

                Created:
                Updated: