Mansoor, Ghazenfer (EDS) wrote:

How about adding this check at one central place, AuthenticationManager?

I am doing this and I do not see any problem. I set the authenticate to
true after successful authentication, and check for isAuthentication()
before every call.


What sets your Authentication.isAuthenticated() back to false at the start of each request?

I would propose the following:

- SecurityContext to provide a startRequest() and finishRequest() method that is called by HttpSessionContextIntegrationFilter.
- The startRequest() and finishRequest() set Authentication.isAuthenticated() to false. Do it twice in case the Authentication is being presented from a remote system (eg via RMI) which has set the isAuthenticated() to true.
- An AuthenticationProvider may, but is not required to, set Authentication.isAuthenticated() to true. If it does set it to true, it means it does not require further callback and the Authentication can safely be used for the remainder of the request. AuthenticationProviders should provide a property setting so this can be switched off (ie they never set the flag to true) as in special situations (like chained AuthenticationProviders or a cache-aware ProviderManager) it might be undesirable.
- AbstractSecurityInterceptor honours the Authentication.isAuthenticated() property by not calling AuthenticationManager if not required. AbstractSecurityInterceptor never sets Authentication.isAuthenticated() (it does at present)


This means there are only two actors changing the Authentication.isAuthenticated() flag: HttpSessionContextIntegrationFilter to clear it, and an AuthenticationProvider to set it.

You are only considering DAO authentication provider here, how about the
other providers that do not have caching?


Most AuthenticationProvider implementations use caching. At least the CAS, X.509 and DAO providers do, and they're the main ones people use. Besides, I was supporting that we should address this issue, just noting it isn't a critical performance issue at present. The benefit of these changes is mainly going to be avoiding unnecessary interaction with collections in ProviderManager and the various caches, plus providing a request-specific hook for future expansion. That should improve performance, although today's collection implementations are fairly well-optimised.

Best regards
Ben



-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click
_______________________________________________
Home: http://acegisecurity.sourceforge.net
Acegisecurity-developer mailing list
Acegisecurity-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer

Reply via email to