[jboss-dev-forums] [Design of Security on JBoss] - Re: SecurityContext

[scott.stark@jboss.org]

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) 

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.


View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3990783#3990783

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3990783