4 Replies Latest reply on Jan 6, 2006 12:21 AM by Anil Saldanha

    Next Generation Security Manager Service

    Anil Saldanha Master

      http://jira.jboss.com/jira/browse/JBAS-2602

      This thread can be dedicated to flesh out details on the new security manager service that is a generalized version of the JaasSecurityManager service.

      Things to discuss:
      1) Identity Holder.
      2) Interfaces the security manager service should support.
      3) Cache design.

      This work will be complemented by the work on:
      a) Generalization of the Tomcat Authentication Framework.
      b) JSR-196 based implementation.

        • 1. Re: Next Generation Security Manager Service
          Anil Saldanha Master

          If the authentication and authorization pieces are made into two seperate services, then the internal cache that they rely on needs to be discussed.

          In the current setup, the cache entry in the security manager holds the following information:

          private LoginContext loginCtx;
          private Subject subject;
          private Object credential;
          private Principal callerPrincipal;
          private long expirationTime;
          /** Is there an active authentication in process */
          private boolean needsDestroy;
          /** The number of users sharing this DomainInfo */
          private int activeUsers;
          


          For discussion purposes, if we split this cache entry into two entries, one for authentication needs and one for authorization, I come up with the following:
          AuthenticationEntry:
          private LoginContext loginCtx;
           private Subject subject;
           private Object credential;
           private long expirationTime;
           /** Is there an active authentication in process */
           private boolean needsDestroy;
           /** The number of users sharing this DomainInfo */
           private int activeUsers;
          


          For the authorization piece,
          AuthorizationEntry:
          private Principal callerPrincipal;
          


          It is not clear to me what other information needs to be stored in the authorization cache entry.

          • 2. Re: Next Generation Security Manager Service
            Scott Stark Master

            The caller principal is a function of authentication. Its just a mapping of the security domain principal to an application domain principal.

            The authorization cache needs whatever acls the domain uses for the authorization decision, roles, permissions, etc.

            We can't force an internal repesentation of the cache onto an implementation. The cache needs to be an opaque construct as the current CachePolicy is, with the contents determined by the implementation using the cache.

            • 3. Re: Next Generation Security Manager Service
              Anil Saldanha Master

               

              "scott.stark@jboss.org" wrote:

              We can't force an internal repesentation of the cache onto an implementation. The cache needs to be an opaque construct as the current CachePolicy is, with the contents determined by the implementation using the cache.


              Yes, the AuthorizationManagerService sets the opaque Cache policy into the AuthorizationManager and it is upto the manager to put whatever it wants in the cache.

              I wanted to know what would be good constituents of a cache entry in the default authorization manager implementation that we will provide. You have answered my question.

              • 4. Re: Next Generation Security Manager Service
                Anil Saldanha Master

                 

                "scott.stark@jboss.org" wrote:
                The caller principal is a function of authentication. Its just a mapping of the security domain principal to an application domain principal.

                In the current implementation, the RealmMapping has the following method.
                public interface RealmMapping
                {
                 /** Map from the operational environment Principal to the application
                 domain principal. This is used by the EJBContext.getCallerPrincipal implentation
                 to map from the authenticated principal to a principal in the application
                 domain.
                 @param principal the caller principal as known in the operation environment.
                 @return the principal
                 */
                 public Principal getPrincipal(Principal principal);
                



                The default implementation for this in the JaasSecurityManager is:
                public Principal getPrincipal(Principal principal)
                 {
                 Principal result = principal;
                 // Get the CallerPrincipal group member
                 synchronized( domainCache )
                 {
                 DomainInfo info = getCacheInfo(principal, false);
                
                 if( info != null )
                 {
                 result = info.callerPrincipal;
                 // If the mapping did not have a callerPrincipal just use principal
                 if( result == null )
                 result = principal;
                 info.release();
                 }
                 }
                 return result;
                 }
                


                So even though the CallerPrincipal is a function of the authentication process, it is RealmMapping that is currently using it (in the JBossSX layer).