instead of just a Subject representing the security context, we should have a security context that contains a Subject, trust domain info, authorization info/pointers, etc to allow better integratin/reuse of authorization aspects.

There is a need for an unified Security Context that holds both the authentication and authorization aspects together. I would like to get ideas on this from the community.

We already have SecurityAssociation acting as a central security floater (that takes care of the subject/runasidentity etc).

Where would this Security Context reside?

In my experiment, I tried a SC that was fitted inside the SA in a threadlocal, but ran into thread safety issues.

Given this, SecurityAssociationValve in the web layer checks for existence of SC. If not create one and set in the SA and clear it in the finally block (if they had set it). The same is done by the EJB SecurityInterceptor. This ensures that the SC is cleared up.

The SecurityContext has to have the authenticated identity(s) as it needs to be a superset of the existing SecurityAssociation context of principal, credential and Subject. I'm thinking of something more like:

We need to workout the trust usecase workflows to define the spi. I don't think its best embeded in the authentication call, but I"m not sure. How would 196 deal with a saml identity assertion?

JSR-196 does not handle it now explicitly. There is support via: a) Access to the Http Request (means access to the SAML Token). The server runtime can do back-door communication via SOAP with a Identity Server for the additional attributes associated with the saml identity. b) Server Runtime can hold state such that there is back and forth communication with the client runtime. Similar to the SPNEGO requirements.

The trust spi needs to support the mapping of one identity to another. SPENGO is an example of a full authentication sequence, not a trust decision. When I think of a trust spi, I'm thinking of having an identity/subject from one authentication domain and I need to map it to the current domain. Currently you have to have the full authentication info for the target domain. A trust spi allows one to query if and what the target domain identity is without performing full reauthentication.

Similar to the SPNEGO authentication sequence because the trust decision (if using SAML) can involve http redirects before the correct saml token arrives with the necessary information (the other alternative is the backdoor soap interaction). That was my reference wrt JASPI.

If there is a need to know additional information about the target identity (like roles), then we will need another method in the authorization manager (The AM implementation will have to query for the attributes of the identity from an external application domain):

A trust decision can involve outside server calls, the same as an authentication decision, but the context is likely missing proof of identity. Rather there is a statement of identity and maybe some attributes along with it. SSO is really a trust decision as opposed to an authentication. Maybe there can be a single trust/authentication spi. Flesh it out with some mocked up test cases of usage we need to support.

An issue that I have noticed with Security Context with reference to RoleMapping is:If we have multiple deployments (A.war,b-ejb.jar,C.war etc) all driven by the same security domain and since the SecurityContext works at the domain level, we can have an issue if the user configures a custom role mapping module for a particular deployment (say, A.war).

So the user may want a subset of roles applicable to deployment A whereas for the other deployments, a superset (or a different set of roles can apply).

Unless we do a fresh creation of security context roles for each lookup of roles, there can be issues(cached roles in the context)

Workaround:a) Provide a system property that is jbosssx specific that configures whether the Authorization Manager does a fresh set of security context roles (read the subject roles if any and apply mapping) on each look up ORb) Provide options on the Authorization Manager Service to be provided to each of the Authorization Managers possible.

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:

For Resource, let's generalize the layer into a type and pull the know types out into a separate ResourceTypes constants class.

- MappingContext/MappingProvider, this seems restrictive in that one has to pass in a mutable mappedObject to the performMapping method. This won't work for Principals, Certificates, credentials. This should also be parameterized to support an expected type:

public interface MappingProvider
{
/**
* Initialize the provider with the configured module options
* @param options
*/
void init(Map options);
/**
* Map the passed object
* @param map A read-only contextual map that can provide information to the provider
* @param input an Object on which the mapping will be applied
* @return the mapping of input
* @throws IllegalArgumentException if the input is not understood by the
* provider.
*/
<T> T performMapping(Map map, T input);
}

With this, we probably want the SecurityContext.getMappingContext(Class mappingType, String key) to allow selection of MappingProvider that support the T,key pair.

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.

I'm not seeing how the run-as identity and roles fits into the SecurityContext. How does it?

I would also like to sketch out how we do the following with the revised spis:

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

- How would we implement the jsr196 authentication?

- How would we configure a scenario where the caller of an ejb was mapped to another identity/credentials for accessing resources like jca connections? For example, a caller derived username/password, principal/credential for a database or jms connection.

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:

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.

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

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.

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