1 2 3 Previous Next 30 Replies Latest reply on Mar 15, 2010 6:15 AM by dimonv

    SecurityContext

    anil.saldhana

      From Scott's quote:

      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.

        • 1. Re: SecurityContext
          anil.saldhana

          Here is the latest on the SecurityContext.

          Associated JIRA issue:
          http://jira.jboss.com/jira/browse/JBAS-3576

          The current prototype has the following minimal contract:

          package org.jboss.security;
          public class SecurityContext
          {
           public AuthorizationManager getAuthorizationManager(String securityDomain);
           public Group getRoles(String securityDomain);
          }
          


          Plugged into an InheritableThreadLocal in SecurityAssociation.

          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.





          • 2. Re: SecurityContext
            starksm64

            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:

            class SubjectInfo
            {
             Principal authenticationPrincipal;
             Object authenticationCredential;
             Subject subject;
            }
            class abstract SecurityContext
            {
             /** Key into the data map for the java.security.acl.Group representing the user roles
             Group roles = (Group) sc.getData().get(ROLES);
             */
             public final String ROLES = "ROLES";
            ...
            
             SubjectInfo getSubjectInfo();
             HashMap<String, Object> getData();
             public AuthorizationManager getAuthorizationManager();
            }
            


            We also need an extension of the AuthenticationManager to deal with the mapping of identity and trust.

            • 3. Re: SecurityContext
              anil.saldhana

              Carlo, lets discuss (over IM) and/or the following design forum thread:
              http://www.jboss.com/index.html?module=bb&op=viewtopic&t=89517


              Scott, to continue with the Security Context discussion here.

              * Do you envisage that the roles contained in the SC are an union of all roles applicable in the call path (with possibly multiple security domains)?

              * I am not 100% clear on our Trust needs in the AuthenticationManager. Are we looking at accomodating JaasSecurityDomain notion of trust in the AM?

              • 4. Re: SecurityContext
                starksm64

                Both the context data(such as roles) and authorization manager should be a function of the security domain.

                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?

                • 5. Re: SecurityContext
                  anil.saldhana

                   

                  "scott.stark@jboss.org" wrote:

                  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.

                  • 6. Re: SecurityContext
                    starksm64

                    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.

                    • 7. Re: SecurityContext
                      anil.saldhana

                      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.

                      For the trust spi, how does the following look:

                      /**
                      Principal can be null. The Contextual map can contain additional subjectInfo plus other info including a SAML Token assertion/domainInfo from the source application domain
                      */
                      Principal getTargetIdentity(Principal p, Map contextualMap);
                      


                      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):
                      Group getTargetRoles(Principal targetIdentity, Map contextualMap)
                      


                      • 8. Re: SecurityContext
                        starksm64

                        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.

                        • 9. Re: SecurityContext
                          anil.saldhana

                          Now that we are clear on the constituents of the Security Context (Superset of the Security Association), I would like to discuss the establishment of the SC (and/or in relation to SA).

                          In my current prototype for the time being, I plugged in the SC in the Security Association as a map entry in the context data keyed in by security domain. I think this is not right.

                          - What do we do with Security Association?

                          • 10. Re: SecurityContext
                            anil.saldhana

                            Scott would like to see the SecurityAssociation legacy framework replaced with the new Security SPI setup.
                            http://jira.jboss.com/jira/browse/SECURITY-14

                            • 11. Re: SecurityContext
                              anil.saldhana

                              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 OR
                              b) Provide options on the Authorization Manager Service to be provided to each of the Authorization Managers possible.

                              I like b)

                              • 12. Re: SecurityContext
                                anil.saldhana

                                Scott, can you comment on the following wiki that describes my thoughts on a possible setup of Security Context versus the legacy Security Association.
                                http://wiki.jboss.org/wiki/Wiki.jsp?page=SecurityContextReplaceSecurityAssociation

                                Thread local stacks for RAI and subject in SA will not be needed anymore as the SC will hold the info. SA will hold just one threadlocal SC stack.

                                • 13. Re: SecurityContext
                                  starksm64

                                  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.


                                  • 14. Re: SecurityContext
                                    anil.saldhana

                                    Thanks Scott for the feedback!


                                    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.

                                    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.

                                    1 2 3 Previous Next