I have a usecase where there is a clear mismatch on what is put on the SecurityAssociation thread local principal stack and what you really want. Usecase: * User logs into a web application with form auth. * JBoss Security Mgr creates a SimplePrincipal of the username and passes to the Jaas framework. * A login module creates a custom view of the username via a Custom Principal and into the shared state map. * ClientLoginModule populates the SA threadlocal stack with the custom principal. * Now that the form authentication is fine, the JBossSecurityMgrRealm populates the SA stack with subjectcontext. Now in the servlet, the user makes a call on an ejb (no jaas login). This time the security interceptor in the proxy picks up the principal on the SA stack (which happens to be the SimplePrincipal). I think this case falls through the crack for providing end-to-end security. Workaround: a) Have an explicit jaas login in the servlet such that the ClientLoginModule places the custom principal again on the SA stack. Issue is that there needs to be a way for the password to be obtained. b) Provide an additional option on the JBossSecurityMgrRealm to plug in a custom principal class, such that this principal class gets pushed on the SA stack rather than the simple principal. I like option b) Any other thoughts? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3973351#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...