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

[mashama]

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?

[jbertram]

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.

[mashama]

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

[jbertram]

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").

[mashama]

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. 

[jbertram]

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

[mashama]

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

[mashama]

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. 

[jbertram]

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?

[mashama]

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!