Andreas Prohaska wrote:
I'm using the Acegi Security framework in a Web project for a few days
now, and now I'm not sure whether I don't understand the meaning of
Authentication.isAuthenticated(), or there is an issue with the
ProviderManager
(and possibly DaoAuthenticationProvider).
The basic question is: Why are already authenticated Authentication
instances
authenticated again and again (in the AbstractSecurityInterceptor)? They
are passed to the AuthenticationManager even if
Authentication.isAuthenticated()
would return true, but this is never checked. Is this by design or is this
an issue?
If this is an issue, there might be another one. Since the "authenticated"
property is set to true in the AbstractSecurityInterceptor after the
AuthenticationManager has been called, the authentication in the web tier
would at least be done twice for one session. This happens because the
AuthenticationProcessingFilter calls the AuthenticationManager to
authenticate the Session and then sends a redirect without processing
the chain. So setAuthenticated(true) would never be called in the first
request anyway.
So:
1) Why doesn't the AuthenticationManager set setAuthenticated(true)?
Web views often access the Authentication from the ContextHolder. As a
web view has no way of knowing whether the retrieved Authentication has
been authenticated or not, the Authentication.isAuthenticated() method
is provided. It's only set by AbstractSecurityInterceptor because only
the security interceptor will actually guarantee presentation of the
ContextHolder-held Authentication to an AuthenticationManager.
Authentication.isAuthenticated() is not an "important" method by any means.
2) Why doesn't either the AbstractSecurityInterceptor or any
AuthenticationManager implementation skip the authentication if
isAuthenticated() returns true?
By constantly re-authenticating, the Authentication is guaranteed to
always represent the latest state of the authentication repository. This
is important if an account is disabled (how many times have sys admins
got "the call" saying, "the GM is with <insert employee here> and he's
asked me to ask you to cancel their computer access right away and call
him when it's done"). On a more positive note, it also ensures any
changes in GrantedAuthority[]s are reflected immediately. At a
performance level there is little cost in doing this due to the
inclusion of caching interfaces. I hear someone thinking, "doesn't
caching undermine that use case just mentioned?". No, because the
caching implementations can provide cache eviction methods - they need
not be based on a timeout. The point is it's an implementation option,
which would not exist if relying on Authentication.isAuthenticated() alone.
HTH
Ben
-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php
_______________________________________________
Acegisecurity-developer mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
