4 Replies Latest reply on Jun 24, 2005 11:49 PM by Scott Stark

    Multi-threaded and multi-user EJB client application

    Thomas Cherel Novice


      With JBoss, using the default ClientLoginModule, it seems that I can achieve the following in a multi-threaded EJB client application using JAAS authentication:

      1) All threads are sharing the same user identity, which is the one established by the last call to LoginContext.login.
      This is the default ClientLoginModule behavior.

      2) Each thread can have its own user identity provided that LoginContext.login is called by the thread to establish this identity.
      If a thread did not call LoginContext.login, then the last identity established by the last call to LoginContext.login (from any of the other threads) is used.
      This is the behavior of ClientLoginModule with multi-threaded=true

      Is there a way to give the application control over which identity is associated with which thread?
      Something where LoginContext.login will just create a subject and the client application can just use the created subject and set it as the identity for the current thread programmatically?
      This way, an application is free to call LoginContext.login as many times as it wants, and then decide which threads is using which identity.

      I am pretty sure that by breaking down the code of the ClientLoginModule and by using the SecurityAssociation directly, this can be done, but I was wondering if something like that already exists or if you have any advice or recommendations.

      Thanks.

      Thomas

        • 1. Re: Multi-threaded and multi-user EJB client application
          Thomas Cherel Novice

          By the way, it will also be nice if, in multi-threaded mode, threads that have not been associated with an identity are consideres as unauthenticated (instead of using the identity of the last LoginContext.login).
          I think that such behavior makes more sense.

          Thomas

          • 2. Re: Multi-threaded and multi-user EJB client application
            Scott Stark Master

            The pattern in jaas is:

            // Set identity
            LoginContext.login
            ...
            
            // Clear identity
            LoginContext.logout
            


            A Subject is a by-product of authentication. It is not an authentication token that can be generally used in place of the username/password used to create the Subject.

            If you don't want to deal with jaas on the client side, see:
            http://wiki.jboss.org/wiki/Wiki.jsp?page=JndiLoginInitialContextFactory

            • 3. Re: Multi-threaded and multi-user EJB client application
              Thomas Cherel Novice

              Scott,

              I do want to deal with JAAS on the client side (I want to use JAAS for authentication).
              But I also have a requirement for a multi-threaded and multi-user EJB client application and I am trying to understand how, within the same EJB client (same JVM) I can deal with multiple authentication across multiple threads.
              The multi-threaded capabilities of the ClientLoginModule is giving part of the answer, but not completely.
              I was actually hoping to have something "a la" Subject.doAs of JAAS which basically allows me, at any point in time and in any threads, to decide what is the subject used to execute a particular action.
              Subject.doAs is a little painful to deal with as all the business logic must be wrapped into PriviledgedAction, but something simpler where the Subject for the current thread can be set will be nice.

              Actually, after going through some of the JAAS documentation and spec, I do not think that the intend was for LogingContext.login to set the identity (for the current thread or process).
              LoginContext.login is just to authenticate the user (and produce a resulting Subject) and then Subject.doAs is the call really setting the Subject for a specific action.
              I agree, in a J2EE client/server environment, the mapping is not that easy to do (and it is not like if the J2EE spec clearly stated how to do it....).

              Nonetheless, in a multi-tier environment, I can definitely see some needs for J2EE clients that must managed multi users and threads at the same time, in the same process.

              By the way, both WebSphere and WebLogic provide such mechanism (some kind of runAs mechanism).
              WebSphere does it very nicely, I think, since, without and explicit runAs (or setRunAs to set a subject as the "current" subject for the thread which is really making it easier), calls to the server are done as unauthenticated calls. This allows the application to be in full control of the security context (identity) used to invoke the server.

              Thomas

              • 4. Re: Multi-threaded and multi-user EJB client application
                Scott Stark Master

                Its true that JAAS has nothing to do with setting identity, but there is nothing in J2EE that does. The only that this is even mentioned as an authentication mechanism in J2EE is JAAS, so that is what jboss uses. The Subject that results is irrelevant in terms of an identity proxy. Doing a JAAS login that produces a Subject, even if actual authentication is involved is essentially the same as:

                Subject s = new Subject();
                s.getPrincipals().add(new SomePrincipal());
                


                The login modules may add extra stuff, but the end product may have nothing as there is no contract for what a Subject contains. In the absense of a SecurityManager, anyone can create a Subject with whatever they want in it as well, so why am I going to trust it?

                The only thing we could change it to have the ClientLoginModule put the credentials into the Subject under some jboss specific type and add a wrapper around the SecurityAssociation that took the Subject and reproduced the current behavior of the ClientLoginModule. The JndiLoginInitialContextFactory I referenced is already once such wrapper. It just happens to take the Principal and credentials passed to the InitialContext environment.

                There already is an org.jboss.security.AltClientLoginModule that takes the SecurityAssociation principal from the Subject and it could be updated to store the credentials in the Subject for use by JndiLoginInitialContextFactory or some other run as wrappers. Indirection solves everything.