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.

 

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

 

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