I do not think we will provide such a capability. I am not sure whether J2EE app servers are supposed to mandatorily provide support for Subject.doAs
There is no requirement, but define the usecase in question. You can configure the use of Subject.doAs by using subject based permissions with a security manager. However, jboss containers are not going to automatically map existing authorization checks to jacc permissions. If jacc is being used, and a security manager is in use, it should just work.
I am happy to report that my "quick & dirty" implementation of the custom JBoss client login module and doAs() works like a charm. My implementation is based on the JBoss source code and comprises of mainly two classes: MyClientLoginModule and MySecurityAssociation. MyClientLoginModule is the new client login module that replaces the original ClientLoginModule in the JAAS configuration. MySecurityAssociation complements the original SecurityAssociation class with the new doAs() implementation.
- I tried to create the cache for cridentials in the new login module, but it didn't work when the doAs() was called in the server side. Our server seems to login only once and reuse the same subject over and over again. However, in some of the server threads, the cridential cache doesn't get copied; copying of the cridential cache is supposed to work only in the child threads, but some of our threads may not be a direct child, but independent. Anyway, I ended up caching the cridential in the subject itself. This is somewhat risky when the cridential is a clear text password.
- The JBoss doAs() simply calls the JBoss pushSubjectContext with the criential before the Subject.doAs() call and it calls the JBoss popSubjectContext afterwards.
This should be something that RedHat/JBoss could easily implement. I am not sure why it should be done by the user.