Thanks Scott for the feedback! anonymous wrote : | We need to make the SecurityContext an interface (it already essentially is), and define some utility methods for accessing key Subject info so that consumers don't have to know how the Subject/SubjectInfo maintain info for things like: | | - String getUsername(SubjectInfo s) | - Principal getUserPrincipal(SubjectInfo s) | No issue with that. anonymous wrote : We also want to move away from requiring a thread local as an aspect of the spi. In general the call context metadata should contain the SecurityContext, and security aspects would access this. For some apis like JACC we may still need integration via thread locals. | We have to have just one setup. JACC is just installation of a policy and a jacc authorization module. So the call metadata is fine. anonymous wrote : I'm not seeing how the run-as identity and roles fits into the SecurityContext. How does it? RunAsIdentity is not applicable to every JEMS project. It is more of an JEE aspect. Both RAI and Roles will be keyed in the context map inside SC. anonymous wrote : How would we implement the jsr196 authentication? An additional isValid method in the AuthenticationManager interface with the parameters being the wrapper request/response types for the layers. anonymous wrote : - Validate incoming calls that have no authentication info. This could be a trusted call based on internal run-as, external run-as with trust assertion, external run-as with trust based on known hosts, external run-as based on trusted transport cert. Intra-vm will be easier. But the inter-vm association will be complex. I have not thought about it yet. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3991391#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...