Security domain does NOT work for <subsystem xmlns="urn:jboss:domain:messaging:2.0">!!!

[ybxiang.china]

Dear jboss guys,

         I debugged the login module "org.jboss.security.auth.spi.DatabaseServerLoginModule" in wildfly8-CR1, the result is:

• when client code {EJBClientContext.getCurrent().registerInterceptor(0,new ClientSessionTokenInterceptor());} is executed, org.jboss.security.auth.spi.DatabaseServerLoginModule.getUsersPassword() and getRoleSets(...) is called as expect! And other EJB invocations work well too.
• When "jms/HTTPConnectionFactory" is looked up on the client side, DatabaseServerLoginModule.getUsersPassword() is NOT called, and the client print bellow exception:

"JBREM000200: Remote connection failed: javax.security.sasl.SaslException: Authentication failed: all available authentication mechanisms failed"

"javax.naming.NamingException: Failed to connect to any server. Servers tried: [http-remoting://localhost:80]"

So, I guess the Security domain does NOT work for <subsystem xmlns="urn:jboss:domain:messaging:2.0"> at all!!!

Have you tested this case???

Please help me!!!  (After I solved this problem, I will summarize it and post it here, I think it is useful to other guys.)

Thank you very much!

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

1. standalone.xml

http://javaarm.com/file/jboss/ApplicationServer/wildfly/wildfly8-messaging-security/standalone.xml

2. Client

2.1 vm arguments

-Dosgi.requiredJavaVersion=1.6 -Xms40m -Xmx512m -XX:+HeapDumpOnOutOfMemoryError -Xms256m -Djavax.net.ssl.trustStore=D:\java\wildfly-8.0.0.CR1_njnms\standalone\configuration\client.truststore -Djavax.net.ssl.trustStorePassword=ybxiang_truststore_password -Dupdate.site=nms-client -Dignore.rmi.address.cache=true

2.2 program arguments

-os ${target.os} -ws ${target.ws} -arch ${target.arch} -nl ${target.nl} -consoleLog zh_CN

2.3 Client Java Class

http://javaarm.com/file/jboss/ApplicationServer/wildfly/wildfly8-messaging-security/ServerLink.java

http://javaarm.com/file/jboss/ApplicationServer/wildfly/wildfly8-messaging-security/ClientSessionTokenInterceptor.java

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

3. Trying other security-domain definition

3.1 I defined new security domain:

	<security-domain name="messaging-security-domain" cache-type="default">
	<authentication>
	<login-module code="UsersRoles" flag="required">
	<module-option name="usersProperties" value="application-users.properties"/>
	<module-option name="rolesProperties" value="application-roles.properties"/>
	</login-module>
	</authentication>
	</security-domain>

3.2 Add username/password/role through add-user.bat

username: guest

password: guest

role:guest

3.3 client test

Bellow client code still prints the above exception.

public class SimpleClient {

    public static String serverIP = "localhost";

    public static String serverHttpPort = "80";

    public static String username = "guest";

    public static String password = "guest";

    public static void main(String[] args) throws NamingException {

        InitialContext initialContext = null;

        try

        {

            // Step 1. Create an initial context to perform the JNDI lookup.

            final Properties env = new Properties();

            env.put(Context.INITIAL_CONTEXT_FACTORY,"org.jboss.naming.remote.client.InitialContextFactory");

            env.put(Context.PROVIDER_URL, "http-remoting://" + serverIP + ":"+serverHttpPort);

            env.put(Context.SECURITY_PRINCIPAL, username);

            env.put(Context.SECURITY_CREDENTIALS, password);

            initialContext = new InitialContext(env);

            ConnectionFactory cf = (ConnectionFactory) initialContext.lookup("/jms/HTTPConnectionFactory");// "jms/HTTPConnectionFactory" is OK too!

            try{

                JMSContext context = cf.createContext(username, password);

                TemporaryQueue tempQueue = context.createTemporaryQueue();

                context.createProducer().send(tempQueue, "hello");

                JMSConsumer consumer = context.createConsumer(tempQueue);

                String response = consumer.receiveBody(String.class, 2000);

                System.out.println("response = " + response);

            }catch(Exception e){

                e.printStackTrace();

            }

        } finally {

            if (initialContext != null)

            {

                initialContext.close();

            }

        }

    }

}

[ybxiang.china]

I debugged one day again, at last, I debugged into org.jboss.remoting3.remote.ClientConnectionOpenListener.Capabilities.handleEvent(ConnectedMessageChannel).

And found that saslMechs contains only one "PLAIN", so, I guessed that factories.get(mechanism) returns null!

                final Set<SaslClientFactory> factorySet = factories.get(mechanism);

So, I googled SaslClientFactory, nothing useful.

Then I searched SASL in 2.4.0.Final_2013-12-16\hornetq-2.4.0.Final\examples, and find bellow line in MDBRemoteClientExample.java

                env.put("jboss.naming.client.connect.options.org.xnio.Options.SASL_POLICY_NOPLAINTEXT", "false");

Then, I add this line to my codes, it works well!

[jaikiran]

You found the right solution. Since your server side authentication is backed by JAAS, you have to allow plain text SASL authentication mechanism so that the credentials are passed in plain text. To do that you have to set the appropriate property while creating the remoting connection. In this case, since you are using remote naming to manage the remoting connections, you have to use the jboss.naming.client.connect.options.org.xnio.Options.SASL_POLICY_NOPLAINTEXT property and set the value to "false" to allow plain text mechanism to be picked up.

By the way, you might also want to disable the "local client auth" mechanism (which only is useful in dev environments) by setting the following:

env.put("jboss.naming.client.connect.options.org.xnio.Options.SASL_DISALLOWED_MECHANISMS", "JBOSS-LOCAL-USER");

[ybxiang.china]

Thank you for your detailed explanation, sir!

I will study XNIO before long, I think it is necessary.

It is a excellent component, maybe someday I can use it in other cases.

Thank your sir, again!