[jw]

Pretty much the same as apparaonali's:

jboss-ejb-client.properties

{code}
remote.connectionprovider.create.options.org.xnio.Options.SSL_ENABLED=false
remote.connections=default
remote.connection.default.host=localhost
remote.connection.default.port=4447
remote.connection.default.connect.options.org.xnio.Options.SASL_POLICY_NOANONYMOUS=false
remote.connection.default.connect.options.org.xnio.Options.SASL_DISALLOWED_MECHANISMS=JBOSS-LOCAL-USER
remote.connection.default.connect.options.org.xnio.Options.SASL_POLICY_NOPLAINTEXT=false
{code}

jndi.properties

{code}
java.naming.factory.url.pkgs=org.jboss.ejb.client.naming
java.naming.factory.initial=org.jboss.naming.remote.client.InitialContextFactory
{code}

Remote client code:

{code}
ctx = loadFromJndiPropertiesFile();
ctx.put("jboss.naming.client.ejb.context", true); // can not be in jndi.properties. Requieres boolean, does not accept String
ctx.put(InitialContext.PROVIDER_URL,  "remote://localhost:4447");
ctx.put(InitialContext.SECURITY_PRINCIPAL, username);
ctx.put(InitialContext.SECURITY_CREDENTIALS, password);
ctx.lookup(.....);
{code}

Server config:

{code:xml}
        <subsystem xmlns="urn:jboss:domain:remoting:1.1">
            <connector name="remoting-connector" socket-binding="remoting"/>
        </subsystem>
        <subsystem xmlns="urn:jboss:domain:security:1.1">
            <security-domains>
                <security-domain name="my-security-domain" cache-type="default">
                    <authentication>
                        <login-module code="Database" flag="required">
                            <module-option name="dsJndiName" value="java:/MyDS"/>
                            <module-option name="principalsQuery" value="......."/>
                            <module-option name="rolesQuery" value="......."/>
                            <module-option name="hashAlgorithm" value="SHA"/>
                            <module-option name="hashEncoding" value="BASE64"/>
                        </login-module>
                    </authentication>
                </security-domain>
            </security-domains>
       </subsystem>
{code:xml}

In addition I wanted to link the ApplicationRealm to my-security-domain:

{code}
   <management>
        <security-realms>
            <security-realm name="ApplicationRealm">
                <authentication>
                    <jaas name="my-security-domain"/>
                </authentication>
            </security-realm>
        </security-realms>
    </management>
{code}

but that hasn't worked, so I had to remove the security realm of remoting

jboss-app.xml (in META-INF of my ear):

{code:xml}
<jboss-app>
  <security-domain>my-security-domain</security-domain>
</jboss-app>
{code:xml}

[dlofthouse]

Without the security realm on the remoting connection there is no way you can call a secured EJB - lets take a step back and restore that and look at the issue you encounter when that is in place.

[apparaonali]

Thanks for the suggestions and with these suggestions it went ahead, I am getting below errors(Underlined) at server side while accessing the secured ejb. Now user name and password are getting passed to server, however password is not matching. Same database was working for jboss6.

I attached testcase and standalone.xml.

13:38:17,435 TRACE [org.jboss.security.auth.spi.DatabaseServerLoginModule] (Remoting "alh-anxp-dt" task-1) initialize
13:38:17,435 TRACE [org.jboss.security.auth.spi.DatabaseServerLoginModule] (Remoting "alh-anxp-dt" task-1) Security domain: AppuLogin
13:38:17,435 TRACE [org.jboss.security.auth.spi.DatabaseServerLoginModule] (Remoting "alh-anxp-dt" task-1) Password hashing activated: algorithm = SHA-256, encoding = base64, charset = {default}, callback = null, storeCallback = null
13:38:17,435 TRACE [org.jboss.security.auth.spi.DatabaseServerLoginModule] (Remoting "alh-anxp-dt" task-1) DatabaseServerLoginModule, dsJndiName=java:/jdbc/MyDs

13:38:17,451 TRACE [org.jboss.security.auth.spi.DatabaseServerLoginModule] (Remoting "alh-anxp-dt" task-1) principalsQuery=select password from sessionuser where name=?
13:38:17,451 TRACE [org.jboss.security.auth.spi.DatabaseServerLoginModule] (Remoting "alh-anxp-dt" task-1) rolesQuery=select role, 'Roles' from sessionrole where name=?
13:38:17,451 TRACE [org.jboss.security.auth.spi.DatabaseServerLoginModule] (Remoting "alh-anxp-dt" task-1) suspendResume=true
13:38:17,451 TRACE [org.jboss.security.auth.spi.DatabaseServerLoginModule] (Remoting "alh-anxp-dt" task-1) login
13:38:17,451 TRACE [org.jboss.security.auth.spi.DatabaseServerLoginModule] (Remoting "alh-anxp-dt" task-1) suspendAnyTransaction
13:38:17,451 TRACE [org.jboss.security.auth.spi.DatabaseServerLoginModule] (Remoting "alh-anxp-dt" task-1) Excuting query: select password from sessionuser where name=?, with username: admin
13:38:17,545 TRACE [org.jboss.security.auth.spi.DatabaseServerLoginModule] (Remoting "alh-anxp-dt" task-1) Obtained user password
13:38:17,545 TRACE [org.jboss.security.auth.spi.DatabaseServerLoginModule] (Remoting "alh-anxp-dt" task-1) resumeAnyTransaction
13:38:17,545 DEBUG [org.jboss.security.auth.spi.DatabaseServerLoginModule] (Remoting "alh-anxp-dt" task-1) Bad password for username=admin
13:38:17,545 TRACE [org.jboss.security.auth.spi.DatabaseServerLoginModule] (Remoting "alh-anxp-dt" task-1) abort

I am getting below exceptions at client side.

Feb 22, 2012 1:38:17 PM org.jboss.remoting3.remote.RemoteConnection handleException

ERROR: JBREM000200: Remote connection failed: javax.security.sasl.SaslException: Authentication failed: all available authentication mechanisms failed
Feb 22, 2012 1:38:17 PM org.jboss.ejb.client.remoting.ConfigBasedEJBClientContextSelector setupEJBReceivers
WARN: Could not register a EJB receiver for connection to remote://localhost:4447
java.lang.RuntimeException: javax.security.sasl.SaslException: Authentication failed: all available authentication mechanisms failed
at org.jboss.ejb.client.remoting.IoFutureHelper.get(IoFutureHelper.java:91)
at org.jboss.ejb.client.remoting.ConfigBasedEJBClientContextSelector.setupEJBReceivers(ConfigBasedEJBClientContextSelector.java:115)
at org.jboss.ejb.client.remoting.ConfigBasedEJBClientContextSelector.<init>(ConfigBasedEJBClientContextSelector.java:77)
at org.jboss.ejb.client.EJBClientContext.<clinit>(EJBClientContext.java:76)
at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:120)
at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:104)
at $Proxy0.getPrincipal(Unknown Source)
at demo.RemoteEJBClient.invokeStatelessBean(RemoteEJBClient.java:73)
at demo.RemoteEJBClient.main(RemoteEJBClient.java:65)
Caused by: javax.security.sasl.SaslException: Authentication failed: all available authentication mechanisms failed
at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:315)
at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:214)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:72)
at org.xnio.channels.TranslatingSuspendableChannel.handleReadable(TranslatingSuspendableChannel.java:189)
at org.xnio.channels.TranslatingSuspendableChannel$1.handleEvent(TranslatingSuspendableChannel.java:103)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:72)
at org.xnio.nio.NioHandle.run(NioHandle.java:90)
at org.xnio.nio.WorkerThread.run(WorkerThread.java:184)
at ...asynchronous invocation...(Unknown Source)
at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:270)
at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:251)
at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:349)
at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:333)
at org.jboss.ejb.client.remoting.ConfigBasedEJBClientContextSelector.setupEJBReceivers(ConfigBasedEJBClientContextSelector.java:113)
... 7 more
java.lang.IllegalStateException: No EJB receiver available for handling [appName:TestEAR,modulename:TestEJB,distinctname:] combination
at org.jboss.ejb.client.EJBClientContext.requireEJBReceiver(EJBClientContext.java:530)
at org.jboss.ejb.client.ReceiverInterceptor.handleInvocation(ReceiverInterceptor.java:84)
at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:175)
at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:136)
at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:121)
at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:104)
at $Proxy0.getPrincipal(Unknown Source)
at demo.RemoteEJBClient.invokeStatelessBean(RemoteEJBClient.java:73)

at demo.RemoteEJBClient.main(RemoteEJBClient.java:65)

My test details: Added below bold proprties for management realm

jboss-ejb-client.properties:

endpoint.name=client-endpoint
remote.connectionprovider.create.options.org.xnio.Options.SSL_ENABLED=false
remote.connections=default
remote.connection.default.host=localhost
remote.connection.default.port = 4447
remote.connection.default.username=admin
remote.connection.default.password=admin
remote.connection.default.connect.options.org.xnio.Options.SASL_POLICY_NOPLAINTEXT=false
remote.connection.default.connect.options.org.xnio.Options.SASL_POLICY_NOANONYMOUS=false
remote.connection.default.connect.options.org.xnio.Options.SASL_DISALLOWED_MECHANISMS=JBOSS-LOCAL-USER

[dlofthouse]

Thanks for the detailed output - at this point this suggests the realm / domain configuration is correctly configured to be working together, we may need to double check that the correct password is being passed to the login module but from the information I have if the correct username is arriving there I would not suspect the wrong password to be arriving there.

Within your security domain configuration you have configured the module to use both a hashAlgorithm and hashEncoding - what is the actual value stored in the password field of that row of the table?

I would suggest that as a next step to at least verify end to end of this call  that you remove both the hashAlgorithm and hashEncoding values from the domain configuration and update that row of the table so that the password field contains the plain text value 'admin' - if the call can be verified to that point it will mean that attention can then be focussed on the final settings for the DatabaseLoginModule.

[jw]

login is ok now using the following configuration

server config:

{code}
            <security-realm name="ApplicationRealm">
                <authentication>
                    <properties path="application-users.properties" relative-to="jboss.server.config.dir"/>
                </authentication>
            </security-realm>
                <security-domain name="my-security-domain" cache-type="default">
                    <authentication>
                        <login-module code="Remoting" flag="optional">
                            <module-option name="password-stacking" value="useFirstPass"/>
                        </login-module>
                        <login-module code="Database" flag="required">
                            <module-option name="dsJndiName" value="java:/MyDS"/>
                            <module-option name="principalsQuery" value="select password from ......."/>
                            <module-option name="rolesQuery" value="select r.role, 'Roles' from ...."/>
                            <module-option name="hashAlgorithm" value="SHA"/>
                            <module-option name="hashEncoding" value="BASE64"/>
                            <module-option name="password-stacking" value="useFirstPass"/>
                        </login-module>
                    </authentication>
                </security-domain>
{code}

client initial context:

{code}
ctx.put("java.naming.factory.initial", "org.jboss.naming.remote.client.InitialContextFactory");
ctx.put("jboss.naming.client.ejb.context", true); // can not be in jndi.properties. Requieres boolean, does not accept String 
ctx.put(InitialContext.PROVIDER_URL,  "remote://localhost:4447"); 
ctx.put(InitialContext.SECURITY_PRINCIPAL, "test"); 
ctx.put(InitialContext.SECURITY_CREDENTIALS, "tset"); 
{code}

jboss-ejb-client:

{code}
remote.connectionprovider.create.options.org.xnio.Options.SSL_ENABLED=false
remote.connections=default
remote.connection.default.host=localhost
remote.connection.default.port=4447
remote.connection.default.connect.options.org.xnio.Options.SASL_POLICY_NOANONYMOUS=true
remote.connection.default.connect.options.org.xnio.Options.SASL_DISALLOWED_MECHANISMS=JBOSS-LOCAL-USER
remote.connection.default.connect.options.org.xnio.Options.SASL_POLICY_NOPLAINTEXT=false
remote.connection.default.username=test
remote.connection.default.password=tset
{code}

The key thing was that the username/password must be passed in on 2 places: in the jboss-ejb-client file AND in InitialContext. Is this how it should be or does anyone knows a better solution?

Redirecting the ApplicationRealm to my-security-domain still doesn't work. How has this to be done?

{code}
            <security-realm name="ApplicationRealm">
                <authentication>
                    <jaas name="my-security-domain"/>
                </authentication>
            </security-realm>
{code}

Error is:

Caused by: javax.naming.NamingException: Failed to create remoting connection [Root exception is java.lang.RuntimeException: javax.security.sasl.SaslException: Authentication failed: all available authentication mechanisms failed]

          at org.jboss.naming.remote.client.ClientUtil.namingException(ClientUtil.java:36)

          at org.jboss.naming.remote.client.InitialContextFactory.getInitialContext(InitialContextFactory.java:117)

          at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684)

          at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:307)

          at javax.naming.InitialContext.init(InitialContext.java:242)

          at javax.naming.InitialContext.<init>(InitialContext.java:216)

          at ch.syseca.edis.swing.presentation.ServiceLocator$3.getContext(ServiceLocator.java:123)

          at ch.syseca.sstl.eutil.resourcelocator.ResourceLocator.lookup(ResourceLocator.java:67)

          ... 13 more

Caused by: java.lang.RuntimeException: javax.security.sasl.SaslException: Authentication failed: all available authentication mechanisms failed

          at org.jboss.naming.remote.protocol.IoFutureHelper.get(IoFutureHelper.java:87)

          at org.jboss.naming.remote.client.cache.ConnectionCache.get(ConnectionCache.java:42)

          at org.jboss.naming.remote.client.InitialContextFactory.createConnection(InitialContextFactory.java:153)

          at org.jboss.naming.remote.client.InitialContextFactory.getOrCreateConnection(InitialContextFactory.java:126)

          at org.jboss.naming.remote.client.InitialContextFactory.getInitialContext(InitialContextFactory.java:106)

          ... 19 more

Caused by: javax.security.sasl.SaslException: Authentication failed: all available authentication mechanisms failed

          at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:365)

          at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:214)

          at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:72)

          at org.xnio.channels.TranslatingSuspendableChannel.handleReadable(TranslatingSuspendableChannel.java:189)

          at org.xnio.channels.TranslatingSuspendableChannel$1.handleEvent(TranslatingSuspendableChannel.java:103)

          at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:72)

          at org.xnio.nio.NioHandle.run(NioHandle.java:90)

          at org.xnio.nio.WorkerThread.run(WorkerThread.java:184)

          at ...asynchronous invocation...(Unknown Source)

          at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:270)

          at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:251)

          at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:349)

          at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:333)

          at org.jboss.naming.remote.client.cache.EndpointCache$EndpointWrapper.connect(EndpointCache.java:110)

          at org.jboss.naming.remote.client.cache.ConnectionCache.get(ConnectionCache.java:41)

          ... 22 more

[dlofthouse]

Looking at your stack trace the error is reported when the connection is being established for the InitialContext, have a look towards the end of the following post with examples to set the same xnio Options for the JNDI connection: -

Custom jdbc login module for remoting

[apparaonali]

Thanks for your reply.

I tried the following things but I am getting the same exceptions as mentioned above and server log is also same "Bad Password"

1. Disabled encrypting of passwords by removing the below two lines from standalone.xml

    <module-option name="hashAlgorithm" value="SHA-256"/>
    <module-option name="hashEncoding" value="base64"/>

   Updated the password in database table to plain text

Ran the application appliaction.

2. Tried with blank password, result is same.

[jw]

Thanks for the link. Added the following lines to jndi.properties:

jboss.naming.client.connect.options.org.xnio.Options.SASL_POLICY_NOANONYMOUS=true

jboss.naming.client.connect.options.org.xnio.Options.SASL_DISALLOWED_MECHANISMS=JBOSS-LOCAL-USER

jboss.naming.client.connect.options.org.xnio.Options.SASL_POLICY_NOPLAINTEXT=false

Now I get also the 'Bad Password' message as in the posting before.

[dlofthouse]

Are either of you familiar with debugging JBoss AS source?  If so the easiest thing would be to set a breakpoint and check the values being passed into the validatePassword of UsernamePasswordLoginModule and verify that they are as expected (To be getting the error we see one of them must be wrong)

If not I will see if we can use byteman to output the values for us to vefify.

[mates1234]

Do you know, what is managed by jboss.naming.client.ejb.context?


[apparaonali]

Finally the issue for fixed and able to connect to remote ejbs successfuly.

Actually there is space in password value in ejb client proprties file and due to that it failed.

I build Jboss picketbox(Jboss security) libraries and debugged then I found the reason for the issue.

Once I update the ejb client priorities file I am able to connect to ejbs.

Thanks Darren for constant support to fix the issue.

[ganeshment]

Thanks Daren for helping to fix this issue.

Iam posting below working EJB client API based test program.

package demo;

import java.io.IOException;
import java.net.URI;
import java.security.Security;
import java.util.concurrent.TimeUnit;

import javax.naming.NamingException;
import javax.security.auth.login.LoginException;

import org.jboss.ejb.client.ContextSelector;
import org.jboss.ejb.client.EJBClient;
import org.jboss.ejb.client.EJBClientContext;
import org.jboss.ejb.client.EJBClientTransactionContext;
import org.jboss.ejb.client.StatelessEJBLocator;
import org.jboss.ejb.client.remoting.IoFutureHelper;
import org.jboss.remoting3.Connection;
import org.jboss.remoting3.Endpoint;
import org.jboss.remoting3.Remoting;
import org.jboss.remoting3.remote.RemoteConnectionProviderFactory;
import org.jboss.sasl.JBossSaslProvider;
import org.xnio.IoFuture;
import org.xnio.OptionMap;
import org.xnio.Options;

public class RemoteEJBClient {
   
    /**
     * User login name
     */
    private static final String USER_LOGIN_NAME = "admin";

    /**
     * User password
     */
    private static final String USER_PASSWORD = "admin";
   
    private static Connection connection;
    private static EJBClientContext ejbClientContext;
    private static Endpoint endpoint;

    static {
        Security.addProvider(new JBossSaslProvider());
    }

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

        endpoint = Remoting.createEndpoint("ejb-remote-client-endpoint", OptionMap.EMPTY);

        endpoint.addConnectionProvider("remote", new RemoteConnectionProviderFactory(),
                                       OptionMap.create(Options.SSL_ENABLED, Boolean.FALSE, Options.SASL_SERVER_AUTH,
                                                        Boolean.FALSE));
       
        MyCallbackHandler callbackhndlr = new MyCallbackHandler(USER_LOGIN_NAME, USER_PASSWORD);
         // open a connection
        final IoFuture<Connection> futureConnection = endpoint.connect(new URI("remote://localhost:" + "4447"),
                                                                       OptionMap.create(Options.SASL_POLICY_NOPLAINTEXT,
                                                                                        Boolean.FALSE), callbackhndlr);
        connection = IoFutureHelper.get(futureConnection, 5, TimeUnit.SECONDS);

        ejbClientContext = EJBClientContext.create();
        ejbClientContext.registerConnection(connection);
        @SuppressWarnings("unused")
        final ContextSelector<EJBClientContext> previousSelector = EJBClientContext.setConstantContext(ejbClientContext);

        // setting up something for transactions
        final EJBClientTransactionContext localUserTxContext = EJBClientTransactionContext.createLocal();
        EJBClientTransactionContext.setGlobalContext(localUserTxContext);
       
        invokeStatelessBean();
       

        if (connection != null) {
            try {
                connection.close();
            } catch (IOException ioe) {
                System.out.println("Failed to close connection" + ioe);
            }
        }
        if (endpoint != null) {
            try {
                endpoint.close();
            } catch (IOException ioe) {
                System.out.println("Failed to close endpoint" + ioe);
            }
        }

    }

    private static void invokeStatelessBean() throws NamingException, LoginException {

        final SessionBeanInterface statelessSessionBeanInterface = lookupRemoteStatelessCalculator();
        System.out.println("Obtained a remote stateless SessionBeanInterface for invocation");
        try {
            System.out.println("EJB principal " + statelessSessionBeanInterface.getPrincipal());
        } catch (RuntimeException e) {
            e.printStackTrace();
        }
    }

    private static SessionBeanInterface lookupRemoteStatelessCalculator() throws NamingException, LoginException {
        final String appName = "TestEAR";
        final String moduleName = "TestEJB";
        final String distinctName = "";
        final String beanName = "SessionBean";
        final String viewClassName = SessionBeanInterface.class.getName();
        System.out.println("ejb:" + appName + "/" + moduleName + "/" + distinctName + "/" + beanName + "!" + viewClassName);

        // create a locator depending on the type you are calling: StatelessEJBLocator, EntityEJBLocator, StatefulEJBLocator &
        // create the proxy given the locator
        final StatelessEJBLocator<SessionBeanInterface> locator = new StatelessEJBLocator<SessionBeanInterface>(
                                                                                                                SessionBeanInterface.class,
                                                                                                                appName,
                                                                                                                moduleName,
                                                                                                                beanName,
                                                                                                                distinctName);
        SessionBeanInterface bean = EJBClient.createProxy(locator);
        return bean;
    }

}

[jaikiran]

apparaonali wrote:

Finally the issue for fixed and able to connect to remote ejbs successfuly.

Actually there is space in password value in ejb client proprties file and due to that it failed.

Trailing space to the password value? I wonder if it's a good idea if we trimmed the value.

[dlofthouse]

@jaikiran - it probably does make sense to trip any trailing space at least

[dlofthouse]

One other point revealed by this thread (and a couple of others) is that it is quite difficult to get enough information from the logs to accurately see why a comparison is failing - all logging that outputs passwords has been removed so that passwords are not accidentally stored in the logs but I think there are still a couple of scenarios where there is no other option than logging the values so that they can be manually compared to make sure they are as expected.

I am going to have a look at what options we have for a development environment at least to essentially evaluate the end to end authentication process so that the point of failure can be pinpointed more quickly.