11 Replies Latest reply: May 31, 2012 12:15 PM by rathm1 RSS

Remote Client - Error when switching from 7.1.0 to 7.1.1.

rathm1 Newbie

Hello all,

 

We are having some trouble switching our remote client from 7.1.0 to 7.1.1 and we need to do this because of some performance testing issues that appear to be resolved in 7.1.1.

If we use the code below and first call the findUnique and then the update methods, the update method fails with the error:

ERROR [ServerError] javax.ejb.EJBAccessException: JBAS013323: Invalid User on the client side.

Using the 7.1.0 jboss-client-7.1.0.Final.jar, the error did not occur.

 

On the server side, enabling TRACE for org.jboss.security we see this for the update method being called:

15:47:45,916 TRACE [org.jboss.security.authentication.JBossCachedAuthenticationManager] (EJB default - 6) Begin isValid, principal:5be9354e-b783-4073-a1f3-4c70d1cdbdee, cache entry: null

15:47:45,919 TRACE [org.jboss.security.authentication.JBossCachedAuthenticationManager] (EJB default - 6) defaultLogin, principal=5be9354e-b783-4073-a1f3-4c70d1cdbdee

15:47:45,921 TRACE [org.jboss.security.auth.login.XMLLoginConfigImpl] (EJB default - 6) Begin getAppConfigurationEntry(my_logon), size=4

15:47:45,922 TRACE [org.jboss.security.auth.login.XMLLoginConfigImpl] (EJB default - 6) End getAppConfigurationEntry(my_logon), authInfo=AppConfigurationEntry[]:

[0]

LoginModule Class: org.jboss.security.auth.spi.LdapLoginModule

ControlFlag: LoginModuleControlFlag: optional

Options:

{omitted for security reasons}

[1]

LoginModule Class: org.jboss.security.auth.spi.LdapLoginModule

ControlFlag: LoginModuleControlFlag: optional

Options:

{omitted for security reasons}

 

15:47:45,936 TRACE [org.jboss.security.auth.spi.LdapLoginModule] (EJB default - 6) initialize

15:47:45,937 TRACE [org.jboss.security.auth.spi.LdapLoginModule] (EJB default - 6) Security domain: my_logon

15:47:45,937 TRACE [org.jboss.security.auth.spi.LdapLoginModule] (EJB default - 6) Saw unauthenticatedIdentity=anonymous

15:47:45,939 TRACE [org.jboss.security.auth.spi.LdapLoginModule] (EJB default - 6) login

15:47:45,940 TRACE [org.jboss.security.auth.spi.LdapLoginModule] (EJB default - 6) Logging into LDAP server, env={java.naming.factory.initial=com.sun.jndi.ldap.LdapCtxFactory, unauthenticatedIdentity=anonymous, principalDNPrefix=uid=, java.naming.security.principal=uid=5be9354e-b783-4073-a1f3-4c70d1cdbdee{omitted for security reasons}}

15:47:45,948 DEBUG [org.jboss.security.auth.spi.LdapLoginModule] (EJB default - 6) Bad password for username=5be9354e-b783-4073-a1f3-4c70d1cdbdee

15:47:45,949 TRACE [org.jboss.security.auth.spi.LdapLoginModule] (EJB default - 6) initialize

15:47:45,950 TRACE [org.jboss.security.auth.spi.LdapLoginModule] (EJB default - 6) Security domain: my_logon

15:47:45,951 TRACE [org.jboss.security.auth.spi.LdapLoginModule] (EJB default - 6) Saw unauthenticatedIdentity=anonymous

15:47:45,952 TRACE [org.jboss.security.auth.spi.LdapLoginModule] (EJB default - 6) login

15:47:45,953 TRACE [org.jboss.security.auth.spi.LdapLoginModule] (EJB default - 6) Logging into LDAP server, env={java.naming.factory.initial=com.sun.jndi.ldap.LdapCtxFactory, unauthenticatedIdentity=anonymous, principalDNPrefix=uid=, java.naming.security.principal=uid=5be9354e-b783-4073-a1f3-4c70d1cdbdee {omitted for security reasons}}

15:47:45,961 DEBUG [org.jboss.security.auth.spi.LdapLoginModule] (EJB default - 6) Bad password for username=5be9354e-b783-4073-a1f3-4c70d1cdbdee

15:47:45,963 TRACE [org.jboss.security.auth.spi.LdapLoginModule] (EJB default - 6) abort

15:47:45,963 TRACE [org.jboss.security.auth.spi.LdapLoginModule] (EJB default - 6) abort

15:47:45,964 ERROR [org.jboss.security.authentication.JBossCachedAuthenticationManager] (EJB default - 6) Login failure: javax.security.auth.login.FailedLoginException: Password Incorrect/Password Required

    at org.jboss.security.auth.spi.UsernamePasswordLoginModule.login(UsernamePasswordLoginModule.java:270) [picketbox-4.0.7.Final.jar:4.0.7.Final]

    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.6.0_26]

    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [rt.jar:1.6.0_26]

    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [rt.jar:1.6.0_26]

    at java.lang.reflect.Method.invoke(Method.java:597) [rt.jar:1.6.0_26]

    at javax.security.auth.login.LoginContext.invoke(LoginContext.java:769) [rt.jar:1.6.0_26]

    at javax.security.auth.login.LoginContext.access$000(LoginContext.java:186) [rt.jar:1.6.0_26]

    at javax.security.auth.login.LoginContext$4.run(LoginContext.java:683) [rt.jar:1.6.0_26]

    at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.6.0_26]

    at javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:680) [rt.jar:1.6.0_26]

    at javax.security.auth.login.LoginContext.login(LoginContext.java:579) [rt.jar:1.6.0_26]

    at org.jboss.security.authentication.JBossCachedAuthenticationManager.defaultLogin(JBossCachedAuthenticationManager.java:449) [picketbox-infinispan-4.0.7.Final.jar:4.0.7.Final]

    at org.jboss.security.authentication.JBossCachedAuthenticationManager.proceedWithJaasLogin(JBossCachedAuthenticationManager.java:383) [picketbox-infinispan-4.0.7.Final.jar:4.0.7.Final]

    at org.jboss.security.authentication.JBossCachedAuthenticationManager.authenticate(JBossCachedAuthenticationManager.java:371) [picketbox-infinispan-4.0.7.Final.jar:4.0.7.Final]

    at org.jboss.security.authentication.JBossCachedAuthenticationManager.isValid(JBossCachedAuthenticationManager.java:160) [picketbox-infinispan-4.0.7.Final.jar:4.0.7.Final]

    at org.jboss.as.security.service.SimpleSecurityManager.authenticate(SimpleSecurityManager.java:306) [jboss-as-security-7.1.1.Final.jar:7.1.1.Final]

    at org.jboss.as.security.service.SimpleSecurityManager.push(SimpleSecurityManager.java:272) [jboss-as-security-7.1.1.Final.jar:7.1.1.Final]

    at org.jboss.as.ejb3.security.SecurityContextInterceptor$1.run(SecurityContextInterceptor.java:49) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]

    at org.jboss.as.ejb3.security.SecurityContextInterceptor$1.run(SecurityContextInterceptor.java:45) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]

    at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.6.0_26]

    at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:74) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]

    at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]

    at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:59) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]

    at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]

    at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50) [jboss-as-ee-7.1.1.Final.jar:7.1.1.Final]

    at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]

    at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:43) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]

    at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]

    at org.jboss.as.ee.component.TCCLInterceptor.processInvocation(TCCLInterceptor.java:45) [jboss-as-ee-7.1.1.Final.jar:7.1.1.Final]

    at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]

    at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]

    at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:165) [jboss-as-ee-7.1.1.Final.jar:7.1.1.Final]

    at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.invokeMethod(MethodInvocationMessageHandler.java:302) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]

    at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.access$200(MethodInvocationMessageHandler.java:64) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]

    at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler$1.run(MethodInvocationMessageHandler.java:196) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]

    at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) [rt.jar:1.6.0_26]

    at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) [rt.jar:1.6.0_26]

    at java.util.concurrent.FutureTask.run(FutureTask.java:138) [rt.jar:1.6.0_26]

    at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_26]

    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_26]

    at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_26]

    at org.jboss.threads.JBossThread.run(JBossThread.java:122)

 

15:47:46,005 TRACE [org.jboss.security.authentication.JBossCachedAuthenticationManager] (EJB default - 6) End isValid, false

15:47:46,008 ERROR [org.jboss.ejb3.invocation] (EJB default - 6) JBAS014134: EJB Invocation failed on component RemoteServiceBean for method public abstract com.dto.MyObjectDto com.service.RemoteService.update(com.dto.MyObjectDto): javax.ejb.EJBAccessException: JBAS013323: Invalid User

    at org.jboss.as.ejb3.security.SecurityContextInterceptor$1.run(SecurityContextInterceptor.java:54) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]

    at org.jboss.as.ejb3.security.SecurityContextInterceptor$1.run(SecurityContextInterceptor.java:45) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]

    at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.6.0_26]

    at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:74) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]

    at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]

    at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:59) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]

    at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]

    at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50) [jboss-as-ee-7.1.1.Final.jar:7.1.1.Final]

    at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]

    at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:43) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]

    at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]

    at org.jboss.as.ee.component.TCCLInterceptor.processInvocation(TCCLInterceptor.java:45) [jboss-as-ee-7.1.1.Final.jar:7.1.1.Final]

    at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]

    at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]

    at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:165) [jboss-as-ee-7.1.1.Final.jar:7.1.1.Final]

    at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.invokeMethod(MethodInvocationMessageHandler.java:302) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]

    at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.access$200(MethodInvocationMessageHandler.java:64) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]

    at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler$1.run(MethodInvocationMessageHandler.java:196) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]

    at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) [rt.jar:1.6.0_26]

    at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) [rt.jar:1.6.0_26]

    at java.util.concurrent.FutureTask.run(FutureTask.java:138) [rt.jar:1.6.0_26]

    at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_26]

    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_26]

    at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_26]

    at org.jboss.threads.JBossThread.run(JBossThread.java:122)

 

Previously in the logs we could see the proper username going to the ldap for authorization/authentication.

 

The set up is as follows:

 

jboss-ejb-client.properties:

 

     remote.connections=default

     endpoint.name=client-endpoint

     remote.connection.default.port=4447

     remote.connection.default.host=localhost

     remote.connectionprovider.create.options.org.xnio.Options.SSL_ENABLED=false

     remote.connection.default.connect.options.org.xnio.Options.SASL_POLICY_NOANONYMOUS=false

 

 

Client.java

public class Client {

    private static Properties props = new Properties();

    private static Context context;   

    private RemoteService home;

       

    public Client() {

    }

    private RemoteService createService() {

        try {

            if (home == null) {              

                String jndiHomeName = "ejb:MyEar/MyApp//com.service.RemoteServiceBean!com.service.RemoteService";

                Context context = getInitialContext();

                home = context.lookup(jndiHomeName);               

            }

            return ((RemoteService)home);

        } catch (Exception ex) {

            ex.printStackTrace();

        }

    }

 

    private Context getInitialContext() throws NamingException {

        if(context == null ) {

            props.put(Context.URL_PKG_PREFIXES, "org.jboss.ejb.client.naming");

            props.put(Context.INITIAL_CONTEXT_FACTORY, org.jboss.naming.remote.client.InitialContextFactory.class.getName());

            props.put("jboss.naming.client.ejb.context", true);

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

            props.put(Context.SECURITY_PRINCIPAL, "username");

            props.put(Context.SECURITY_CREDENTIALS, "password");

            context = new InitialContext(props);

        }

        return context;

    }   

   

    public MyObjectDto update(MyObjectDto myObjectDto) {

        try {

            return createService().update(myObjectDto);

        }

        catch (EJBException ex) {

        ex.printStackTrace();

        }

    }

 

    public MyObjectDto findUnique() {

        MyObjectDto myObjectDto = null;

        try {

            myObjectDto = createService().findUnique();

        }

        catch (EJBException ex) {

        ex.printStackTrace();

        }

        return myObjectDto ;

    }

}

 

So to summarize, the 2nd remote method invocation (update in this case) on the same proxy interface fails with an authentication error.

If we again try to call the 1st, it once again works fine (findUnique in this case).

This issue seems to have been introduced in 7.1.1 since going back to the 7.1.0 jar, the error is gone but the performance issues appear again.

 

If anyone has any suggestions to help that would be greatly appreciated, this issue is critical to our application's success.

Thanks.

  • 1. Re: Remote Client - Error when switching from 7.1.0 to 7.1.1.
    Wolf-Dieter Fink Master

    add

    remote.connection.default.username=XX

    remote.connection.default.password=XX

    to your client properties if you use

    props.put(Context.URL_PKG_PREFIXES, "org.jboss.ejb.client.naming");

    Also you can remove all other properties.

     

    This is the common way to do it, see this document

  • 2. Re: Remote Client - Error when switching from 7.1.0 to 7.1.1.
    rathm1 Newbie

    Thanks for the reply.

    Unfortunately we are a multi user system so cannot hard code the username in the client properties.  The example I used is usually set to get the logged in userid and password to put into the Context.SECURITY_PRINCIPAL and Context.SECURITY_CREDENTIALS.

    I tried out your suggestion anyways and it gets the same security failure as the original setup.

    As I mentioned previously, this was working with the 7.1.0 client jar but something seems to have been changed with the 7.1.1 client jar.

  • 3. Re: Remote Client - Error when switching from 7.1.0 to 7.1.1.
    Wolf-Dieter Fink Master

    How do you add the user at server side? Do you use a different login-module?

     

     

    If you want change the user you might need the JBoss specific api at client side. But this is subject to change.

  • 4. Re: Remote Client - Error when switching from 7.1.0 to 7.1.1.
    rathm1 Newbie

    The user is added on the client side with these properties being set in the InitialContext.

     

    props.put(Context.SECURITY_PRINCIPAL, username);
    props.put(Context.SECURITY_CREDENTIALS, password);

     

    The initial context is then used to look up the Interface -> RemoteService. 

    There are roles allowed set up in our ejb-jar.xml on the server side.

    On the server side you can get this user id out using

    sessionContext.getCallerPrincipal().getName()

     

    This is not the problem though.  That is all working.

    If I make a call to a remote method "findUnique", it gets to the server, authorizes and authenticates fine.

    The issue is when I try to use the RemoteService that I had kept from the previous lookup, it should still be ok to use for an invocation of a remote method and should still know about the user id and password that were used in the initial context to do the lookup but when I call the "update" method, the authentication fails because the user id and password seem to have been lost as you can see from the stack trace that I posted in my original post.

    To me this seems to be a bug with the 7.1.1 client jar because changing nothing, it works fine with the 7.1.0 client jar.

  • 5. Re: Remote Client - Error when switching from 7.1.0 to 7.1.1.
    Mike Toggweiler Newbie

    Well, I've got the same problem sending remote username/password from client to server to authenticate user on server side using a custom login module. The modul extends from UsernamePasswortLoginModule und just performs a db based check. Debugging in Jboss 7.1.1 Final Source-code shows the following problem:

     

    in SimpleSecurityManager.push():

     

                     if (userInfo instanceof SubjectUserInfo) {
                        SubjectUserInfo sinfo = (SubjectUserInfo) userInfo;
                        subject = sinfo.getSubject();
    
                        Set pcSet = subject.getPrivateCredentials(PasswordCredential.class);
                        if (pcSet.size() > 0) {
                            PasswordCredential pc = pcSet.iterator().next();
                            p = new SimplePrincipal(pc.getUserName());
                            credential = new String(pc.getCredential());
                            RemotingContext.clear(); // Now that it has been used clear it.
                        }
                    }
                    if (p == null || credential == null) {
                        p = new SimplePrincipal(UUID.randomUUID().toString());
                        credential = UUID.randomUUID().toString();
                    }
    

    So the credential information will only be provided if there exists a PasswordCredential within the Subject create on server side. But checking where the remote subject gets created I found out that only the following principals get created in the ServerConnectionOpenListener:

      private Collection createPrincipals() {
                final Set principals = new LinkedHashSet();
    
                final SslChannel sslChannel = connection.getSslChannel();
                if (sslChannel != null) {
                    // It might be STARTTLS, in which case we can still opt out of SSL
                    final SSLSession session = sslChannel.getSslSession();
                    if (session != null) {
                        try {
                            principals.add(session.getPeerPrincipal());
                        } catch (SSLPeerUnverifiedException ignored) {
                        }
                    }
                }
                String authorizationId = saslServer.getAuthorizationID();
                if (authorizationId != null) {
                    principals.add(new UserPrincipal(authorizationId));
                }
                final ConnectedMessageChannel channel = connection.getChannel();
                final InetSocketAddress address = channel.getPeerAddress(InetSocketAddress.class);
                if (address != null) {
                    principals.add(new InetAddressPrincipal(address.getAddress()));
                }
    
                return Collections.unmodifiableCollection(principals);
            }
    

     

    So, what must be done to get the real credential informations within the custom loginmodule? Or how should the server gets authenticated on server side without this information?

  • 6. Re: Remote Client - Error when switching from 7.1.0 to 7.1.1.
    rathm1 Newbie

    Hi Mike,

    Do you have problems with every server call or only the 2nd or 3rd time you attempt to call a remote method using a cached interface that you had previously looked up?

    If it is everytime, I think your issue is a little bit different than mine.  They could still be related but I just wanted to clarify if it was everytime or not.

    In my case I can get to the server and it authorizes/authenticates fine against the LDAP for the first remote method but using the same interface to call on another remote method is where I run into the problem.

  • 7. Re: Remote Client - Error when switching from 7.1.0 to 7.1.1.
    Mike Toggweiler Newbie

    Hi rathm

     

    In my case the password credential never got submitted to my custom loginmodule and debugging the code didn't help me find the solution. With try and error I found a solution which works for me right now.

    I created a custom loginmodule deployed within every application configured for this security-domain. Because of classloading issues I couldn't configure the default security-domain for remote calls so I still needed an anonymous user to connect to the server (I didn't won't to configure all users in out database and in the user properties file of jboss). Because of this mixing mode I did receive a UUID as credential within my custom login module.

    Know I switched from a custom login module to the DatabaseServerLoginModul which is included in the jboss itself and configured the default security-domain for remote-connections. Within the DatabaseServerLoginModul I do get the password as a hashed credential. I little debugging showed me that this credentials are set within the JAASCallbackHandler but i didn't dig deeper to find the point where the credentials are submitted.

     

    So back to your question:

    My problem did show up on every remote call. It was even worse. Because of the missing password credential within my loginmodule I tried a little workaround and attached the password to the username. With this solution I could authenticate the user on the remote side. But after this I didn't get this authenticated user as callerPrincipal in every sessionbean. From time to time I did get the authenticated user, other times I got the anonymous $local user. Hope my answer helps you find I solution.

  • 8. Re: Remote Client - Error when switching from 7.1.0 to 7.1.1.
    rathm1 Newbie

    Thanks Mike,

    I am still searching for a solution but will post if I make any progress at all.

  • 9. Re: Remote Client - Error when switching from 7.1.0 to 7.1.1.
    rathm1 Newbie

    Hello again Mike,

    You mentioned that you "didn't get this authenticated user as callerPrincipal in every sessionbean. From time to time I did get the authenticated user, other times I got the anonymous $local user.".

    I was wondering if you found a way to solve this.

    It appears that my issue is the same type of thing where in some cases I get my authenticated user on the server side but in other cases the $local user is passed in.

    Any help you can offer is much appreciated!

  • 10. Re: Remote Client - Error when switching from 7.1.0 to 7.1.1.
    Mike Toggweiler Newbie

    Hi rathm

     

    The solution to my problem was declaring the security-realm for the remote-connector of jboss:

    standalone-full.xml

    <security-realm name="aRealm">
                    <authentication>
                        <jaas name="aDomain"/>
                    </authentication>
                </security-realm>
    
                                                    
    <security-domain name="aDomain">
                        <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:jboss/datasources/XXX"/>
                                <module-option name="principalsQuery" value="select passwort from XXX where login=?"/>
                                <module-option name="hashAlgorithm" value="SHA-256"/>
                                <module-option name="hashEncoding" value="base64"/>
                                <module-option name="password-stacking" value="useFirstPass"/>
                            </login-module>
                        </authentication>
                    </security-domain>                                                                                                                                                                                                                                                                                
    <subsystem xmlns="urn:jboss:domain:remoting:1.1">
                <connector name="remoting-connector" socket-binding="remoting" security-realm="metasapi-soa"/>
            </subsystem>
    

     

    After this I configured the client lookup using a dynamically assembled 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.connect.options.org.xnio.Options.SASL_POLICY_NOANONYMOUS=true
    remote.connection.default.connect.options.org.xnio.Options.SASL_POLICY_NOPLAINTEXT=false
    remote.connection.default.connect.options.org.xnio.Options.SASL_DISALLOWED_MECHANISMS=JBOSS-LOCAL-USER
    remote.connection.default.username=system
    remote.connection.default.password=system
    

     

    And the appropriate JNDI Context lookup properties:

    Properties props = new Properties();
    props.put(Context.URL_PKG_PREFIXES, "org.jboss.ejb.client.naming");
              // props.put(Context.INITIAL_CONTEXT_FACTORY,
              // org.jboss.naming.remote.client.InitialContextFactory.class.getName());
    props.put("jboss.naming.client.ejb.context", true);
    props.put("jboss.naming.client.connect.options.org.xnio.Options.SASL_POLICY_NOPLAINTEXT",
                   "false");
    props.put(
                   "jboss.naming.client.connect.options.org.xnio.Options.SASL_DISALLOWED_MECHANISMS",
                   "JBOSS-LOCAL-USER");
    props.put(InitialContext.PROVIDER_URL, getServiceProviderUrl());
    props.put(InitialContext.SECURITY_PRINCIPAL, "system");
    props.put(InitialContext.SECURITY_CREDENTIALS, "system");
    

     

    The jboss-ejb-client.properties can dynamically get created the following way:

    final Properties properties = new Properties();
              try {
                   properties.load(getClass().getResourceAsStream("/jboss-ejb-client.properties"));
              }
              catch (IOException e) {
                   e.printStackTrace();
              }
    
              properties.put("remote.connection.default.username", "aUsernane");
              properties.put("remote.connection.default.password", "aPassword");
    
              // create client configuration
              final EJBClientConfiguration clientConfiguration = new PropertiesBasedEJBClientConfiguration(
                   properties);
    
              // create a context selector
              final ContextSelector contextSelector = new ConfigBasedEJBClientContextSelector(
                   clientConfiguration);
    
              // set the selector for use
              EJBClientContext.setSelector(contextSelector);
    

     

    Hope this will help you. A small sideremark:


    This currently only works for a Jboss-as-7.1.2.Final-SNAPSHOT release I've downloaded once from a nightly build. Since jboss-as-7.2.0.Alpha1-SNAPSHOT is linked from nightly build download page the user doesn't get authenticated using the same configuration. A quick debugging of the jboss code didn't show up the problem. Using the default ApplicationRealm with preconfigured users did work with new Version of JBoss. I did swap once to nightly build during solving the problem, can't say if this solution also works with jboss-as-7.1.1.Final.

  • 11. Re: Remote Client - Error when switching from 7.1.0 to 7.1.1.
    rathm1 Newbie

    Thats Great.

    Thanks Mike!

    I stumbled on something similar yesterday and tried it out.

    It seems that the key is creating the jboss-ejb-client.properties dynamically and setting the remote.connection.default.username and password dynamically as well.

    I guess the solution is similar to Wolf-Dieter Fink's suggestion with the difference being to set the remote.connection.default.username and password dynamically in the code instead of hard coding them in the external property file.

    This seems to be working for me so thanks again to both Mike and Wolf-Dieter for your help!

    And one final quick note that this solution did work in Jboss 7.1.1 Final for me.