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.
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:
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.
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.