9 Replies Latest reply on Mar 10, 2015 1:00 PM by Mashama McFarlane

    Secure remote access discrepancies between Wildfly 8.1 on Linux vs. on Windows

    Mashama McFarlane Novice

      I am not  able to remotely send messages to a queue configured in Wildfly 8.1 running on Linux.  I can literally copy the whole Wildfly installation directory to my Windows machine and it works fine.  The following Arquillian test replicates the issue:

       

      @Test
      @InSequence(1)
      public void testProcessCensusRemote() throws InterruptedException {

       

       

      log.info("testProcessCensusRemote");

       

       

      Context namingContext = null;

       

       

      try {
      Properties env = new Properties();
      env.put(Context.INITIAL_CONTEXT_FACTORY, "org.jboss.naming.remote.client.InitialContextFactory");
      env.put(Context.PROVIDER_URL, "http-remoting://" + host);
      env.put(Context.SECURITY_PRINCIPAL, "guest");
      env.put(Context.SECURITY_CREDENTIALS, "guest");
      namingContext = new InitialContext(env);

       

       

      ConnectionFactory connectionFactory = (ConnectionFactory) namingContext.lookup("jms/RemoteConnectionFactory");
      Destination destination = (Destination) namingContext.lookup("/jms/queue/salesApp");

       

       

      try (JMSContext context = connectionFactory.createContext("guest", "guest")) {
      // try (JMSContext context = connectionFactory.createContext()) {

       

       

      context.createProducer().send(destination, Json.createObjectBuilder()
      .add("invoke", "process-census")
      .add("analysis-id", 2419)
      .build().toString());

       

       

      Thread.sleep(15*60*1000);
      }
      } catch (NamingException e) {
      log.fatal(e, e);
      } finally {
      if (namingContext != null) {
      try {
      namingContext.close();
      } catch (NamingException e) {
      log.fatal(e, e);
      }
      }
      }

       

       

      }

       

      What am I missing here?  Is there some additional OS level configuration required to send messages to a remote JMS queue running in Wildfly 8.1 on LInux?

        • 1. Re: Secure remote access discrepancies between Wildfly 8.1 on Linux vs. on Windows
          Justin Bertram Master

          Are you seeing a particular error message or exception when you try to send to the remote server?  If so, please paste the full details.

          • 2. Re: Secure remote access discrepancies between Wildfly 8.1 on Linux vs. on Windows
            Mashama McFarlane Novice

            My apologizes for forgetting to describe the error I am a seeing.

             

            From the Test report:

            -------------------------------------------------------------------------------

            Test set: com.chp.valuequest.controller.MessagingTest

            -------------------------------------------------------------------------------

            Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 43.551 sec <<< FAILURE! - in com.chp.valuequest.controller.MessagingTest

            testProcessCensusRemote(com.chp.valuequest.controller.MessagingTest)  Time elapsed: 1.765 sec  <<< ERROR!

            javax.jms.JMSSecurityRuntimeException: HQ119031: Unable to validate user: guest

              at org.hornetq.core.protocol.core.impl.ChannelImpl.sendBlocking(ChannelImpl.java:394)

              at org.hornetq.core.client.impl.ClientSessionFactoryImpl.createSessionInternal(ClientSessionFactoryImpl.java:880)

              at org.hornetq.core.client.impl.ClientSessionFactoryImpl.createSessionInternal(ClientSessionFactoryImpl.java:789)

              at org.hornetq.core.client.impl.ClientSessionFactoryImpl.createSession(ClientSessionFactoryImpl.java:326)

              at org.hornetq.jms.client.HornetQConnection.authorize(HornetQConnection.java:705)

              at org.hornetq.jms.client.HornetQConnectionFactory.createConnectionInternal(HornetQConnectionFactory.java:762)

              at org.hornetq.jms.client.HornetQConnectionFactory.createContext(HornetQConnectionFactory.java:139)

              at org.hornetq.jms.client.HornetQConnectionFactory.createContext(HornetQConnectionFactory.java:130)

              at com.chp.valuequest.controller.MessagingTest.testProcessCensusRemote(MessagingTest.java:130)

             

             

            From the server:

            14:49:18,138 INFO  [org.jboss.as.server] (management-handler-thread - 1) JBAS018559: Deployed "opportunity-services.war" (runtime-name : "opportunity-services.war")

            2015-03-06 14:49:22,964 INFO  [com.chp.valuequest.controller.MessagingTest] (default task-1) testProcessCensusRemote

            14:49:22,964 INFO  [com.chp.valuequest.controller.MessagingTest] (default task-1) testProcessCensusRemote

            2015-03-06 14:49:23,108 INFO  [org.xnio] (default task-1) XNIO version 3.2.0.Final

            14:49:23,108 INFO  [org.xnio] (default task-1) XNIO version 3.2.0.Final

            2015-03-06 14:49:23,117 INFO  [org.xnio.nio] (default task-1) XNIO NIO Implementation Version 3.2.0.Final

            14:49:23,117 INFO  [org.xnio.nio] (default task-1) XNIO NIO Implementation Version 3.2.0.Final

            2015-03-06 14:49:23,459 INFO  [org.jboss.remoting] (default task-1) JBoss Remoting version 4.0.0.Final

            14:49:23,459 INFO  [org.jboss.remoting] (default task-1) JBoss Remoting version 4.0.0.Final

            2015-03-06 14:49:25,825 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-3) JBAS017535: Unregistered web context: /OpportunityServices

            • 3. Re: Secure remote access discrepancies between Wildfly 8.1 on Linux vs. on Windows
              Justin Bertram Master

              This looks like a standard security issue to me.  I believe that when a client running on the same machine as the application server connects security is not enforced so that's likely why you don't see this same problem when you run the server locally. 

               

              I recommend you ensure the proper user is added to the server (e.g. use the "add-user" script in the "bin" directory to add an application user named "guest" with a password of "guest" belonging to the group "guest").

              • 4. Re: Secure remote access discrepancies between Wildfly 8.1 on Linux vs. on Windows
                Mashama McFarlane Novice

                When I run the test on the linux box with the Wildfly instance it fails with the same error.  I thought it might have to with whether the client is remote or local but this test scenario suggests otherwise. 

                • 5. Re: Secure remote access discrepancies between Wildfly 8.1 on Linux vs. on Windows
                  Justin Bertram Master

                  Can you confirm that you've added the proper user in the proper group as I recommended previously?

                  • 6. Re: Secure remote access discrepancies between Wildfly 8.1 on Linux vs. on Windows
                    Mashama McFarlane Novice

                    Yes.  I can confirm that there is an application user 'guest' with password 'guest' assigned a the 'guest' role.

                    • 7. Re: Secure remote access discrepancies between Wildfly 8.1 on Linux vs. on Windows
                      Mashama McFarlane Novice

                      I feel like I am overlooking something here.  However the fact that it works when the client is local to the instance running on Windows, but fails when the client is local and remote to the instance running on Linux makes me think there is actually something wrong here.  Don't forget that I literally copied the Wildfly installation from Linux to Windows so both of the installations should be exactly the same.

                       

                      ...

                       

                      Ok I just confirmed that it works when the remote Linux client messages the instance running on Windows. 

                      • 8. Re: Secure remote access discrepancies between Wildfly 8.1 on Linux vs. on Windows
                        Justin Bertram Master

                        One thing you might try is setting <security-enabled>false</security-enabled> in the messaging subsystem on the server running on Linux and seeing if that gets you past the security exception which would confirm that your Windows client is actually connecting to the right server.

                         

                        A few more things...

                        • How are you starting the server on Linux?  Are you passing any command-line parameters?  If so, what are they?
                        • Can you attach the server configuration you're using on Linux?
                        • Can you attach the server.log from the Linux server when you observe this problem?
                        • 9. Re: Secure remote access discrepancies between Wildfly 8.1 on Linux vs. on Windows
                          Mashama McFarlane Novice

                          Thanks to you I finally realized which of my assumptions was wrong.  It was a configuration issue in the test server deployed on Linux causing the connection attempts to go to a different instance deployed on the same Linux box.  I fixed the configuration and everything started to work as intended. 

                           

                          Another tidbit that became clear to me is that because I am using the Arquillian Wildfly Remote container capability the test client was always running in the same container where the JMS queue was configured in.  So all is well ...thanks again!