Currently the JaasSecurityManagerService holds onto all the cached auth identity for security domains.

Are there any usecases where a generic cache flush will be suitable, over and above a flush at the session invalidation level?

Currently there is an injection of a proxy of type "JaasSecurityManagerMBean" into the tomcat service, which makes its way into the SecurityAssociationValve to provide an ability to flushAuthenticationCache on session validation.

This direct dependence on an MBean interface in the tomcat layer can be generalized to use an objectname such that any security service that can provide flushing, can be used in the tomcat layer.

public class SecurityAssociationValve extends ValveBase
{
 /** The service used to flush authentication cache on session invalidation. */
 private JaasSecurityManagerServiceMBean secMgrService;
}

Yes, a weakly typed reflective call is what I was thinking. We do have this pattern already in place with the LoginContext CallbackHandler needing a "setSecurityInfo" method.

The Valve already has a reference to the mbean server via the "mserver" attribute.

SecurityAssociationValve::

//private JaasSecurityManagerServiceMBean secMgrService;
private ObjectName secMgrService;

 private void flushAuthenticationCache(String securityDomain, Principal authPrincipal)
{
 try
 {
 mserver.invoke(secMgrService,"flushAuthenticationCache", new Object[]
{securityDomain, authPrincipal}, new String[]{"java.lang.String", "java.security.Principal"});
 }
 catch(JMException e)
 {
 log.debug("Error while flushingAuthenticationCache::" + e.getLocalizedMessage());
 }
}

I was just pointing out the dependence of the tomcat layer on an MBean interface.

The session invalidation cache flush should be handled atleast by a sessionlistener instead of the valve as this JIRA issue suggests.

Regarding providing an higher level cache flushing facility, won't an externalized authentication manager service with flush capability suffice? Whether the flush happens at session invalidation or midway is external to the authentication service that maintains the cache. Or am I missing the picture?

When the session is destroyed, my sessionlistener can capture the event. It has information on the securitydomain via the webmetadata.

The question is should we flush the authenticationcache for the security domain? or for the last known authenticated principal?

Is it right to say that if the Jacc subject is available from the SubjectContextPolicyHandler, consider it before you think about the Active Subject from the security manager service?

Scott says:
YES