Need a clarification

[john017]

Is the AuthenticationManager called for every request.
My filters are configured as follows(as in sample) where httpSessionContextIntegrationfilter is called first.
<bean id="filterChainProxy" class="net.sf.acegisecurity.util.FilterChainProxy">
<property name="filterInvocationDefinitionSource">
<value>
CONVERT_URL_TO_LOWERCASE_BEFORE_COMPARISON
PATTERN_TYPE_APACHE_ANT
/**=httpSessionContextIntegrationFilter,authenticat ionProcessingFilter,rememberMeProcessingFilter,ano nymousProcessingFilter,securityEnforcementFilter
</value>
</property>
</bean>
------------------------------------
AuthenticationProcessingFilter,RememberMe and Anonymous are called but note that user has not selected RememberMe.
So,now,code goes to SecurityEnforcementFilter which tries to authenticate
in beforeInvocation even though the authentication object was previously authenticated using LDAP or DB. Why should it go make a authenticationmanager.authenticate every request even if the contextholder contains the Authentication object with authentication set to true?

(Line 396)
Authentication authenticated;

try {
authenticated = this.authenticationManager.authenticate(context
.getAuthentication());
} catch (AuthenticationException authenticationException) {
AuthenticationFailureEvent event = new AuthenticationFailureEvent(object,
attr, context.getAuthentication(),
authenticationException);
this.context.publishEvent(event);

throw authenticationException;
}
Thanks ,
John

[dwible]

Who better to authenticate then the auth provider?

All i have working from the command line right now is the provider manager and he's just using the daoAuthenticationProvider. Which is better than where I was a week ago. :-)

dw

[john017]

But once authenticated, why keep authenticating again for each request. This is expensive especially with LDAP operations

[Ben Alex]

Because throughout the course of a user session the GrantedAuthority[]s, or enabled/disable status might change. We address the expense by performing caching within most AuthenticationProviders. This allows a caching provider to worry about evicting stale UserDetails from the cache when required.

[john017]

We are having performance issues because of this scenario:
1. We have 3 different authenticationProviders
LDAP(from sandbox), Database (core acegi ) and JAAS (core acegi)
Even though we enabled cache at each provider, the following problem occurs:
AuthenticationManager is configured to go thru each provider in sequence and if a provider does not have the user it returns null,
But since the user does not exist in LDAP, every request makes a LDAP connection since cache is never populated. Either the user must be associated with null authentication credentials and stored in cache for each provider.
Couldnt AuthenticationManager maintain the cache (like JBoss JAASAuthenticationService) rather than maintain different caches for each provider.
Regards,
John

[Ben Alex]

You would probably be best off writing your own ProviderManager replacement that performs the caching.

Leaving caching at the AuthenticationProvider level offers the most flexibility to ensure all future authentication systems are supported.

Perhaps you could modify ProviderManager to cache the Principal object and which AuthenticationProvider responded. That way the call could go directly to the target AuthenticationProvider, but still allow that AuthenticationProvider to do all the processing. I would be happy to include this sort of change in CVS as well.