5 Replies Latest reply on Dec 3, 2009 8:45 AM by marek.gregor

    ClientLoginModule in a multi-threaded swing client

    slimamar

      Hello,

      I'm using the login module 'ClientLoginModule' in a Swing client standalone to send the login information into the JBoss server EJB.
      Here is the client 'auth.conf' file :
      other {
      org.jboss.security.ClientLoginModule required
      multi-threaded=false;
      };

      When i invoke an EJB method in the thread where the 'LoginContext.login' has been made
      the authentification works fine.
      But when i invoke an EJB method in another thread i have to do
      an another 'LoginContext.login'.

      In the documentation, i read this :
      'multi-threaded=true|false : When set to false the login identity and credentials are global variables that apply to all threads in the VM.
      The default for this option is false.'

      When the multi-threaded is set to false, the login identity is global in the VM
      but i have to do a 'LoginContext.login' in each thread.

      What's wrong ?

      Thanks in advance.

        • 1. Re: ClientLoginModule in a multi-threaded swing client
          lucifer002

          I have the same Problem with jboss-5.0.1.GA.

          Strange is, when i'm doing the loggin in the main method, all is fine, when i'm using a LoginDialog, to get username and Password, i get a EJBAccessException in another Thread

          • 2. Re: ClientLoginModule in a multi-threaded swing client
            deepakbyu

            I'm running into this same issue. I am developing remote services for a swing client using JBoss 5.01. The problem does pop up when the the LoginContext login() is called from a thread. We currently have a thread that handles the login, and other threads that handle subsequent calls. Any ideas on how this might be resolved?

            Someone I know did mention this could have to do with some data being stored in ThreadLocal on login().

            • 3. Re: ClientLoginModule in a multi-threaded swing client
              bbunderson

              The security information will propagate to the child threads of the parent thread. If you login with the parent thread then the child threads that you start up later should not need to re-authenticate. At least that is what worked for us.

              http://docs.huihoo.com/javadoc/jboss/4.0.2/org/jboss/security/SecurityAssociation.html

              • 4. Re: ClientLoginModule in a multi-threaded swing client
                anil.saldhana

                https://jira.jboss.org/jira/browse/SECURITY-415

                Try the workaround specified in the JIRA issue. Tell us if the workaround works.

                • 5. Re: ClientLoginModule in a multi-threaded swing client

                  I found the same bug in JBoss 5.1.0GA (bundled with jbosssx-client.jar, version 2.0.3.SP1):

                  Security context is lost in client (multi-threaded swing) application started via java web start, when I perform ejb3 call on different thread, from which I have performed login() on start of the application (login() was perfomed on thread created by java webstart for calling main() method, this thread has been destroyed after finish of main method). Although I have configured:

                  org.jboss.security.ClientLoginModule required
                  multi-threaded=false;

                  Security context is still stored in thread-related storage, what is wrong. After 2 days of remote debugging internals jboss client security library I found problem in static variable SERVER of class org.jboss.security.SecurityContextAssociation, which has declaration:
                  private static boolean SERVER = true; This value is not changed during the run of client application therefore security context is stored in thread local place. Simple workaround which works is to call method SecurityContextAssociation.setClient() before login() method.

                  This bug occured in JBoss 5.1.0GA (jbosssx 2.0.3.SP1) there are already bugfixes which could possibly fix it in newer version of security library, e.g.: https://jira.jboss.org/jira/browse/SECURITY-415, I do not know, it is up on the JBoss people to resolve if it is still valid issue to solve.