[EMAIL PROTECTED] wrote:
Ben,
*Still having trouble submitting to the forum / keeps bouncing back...*
Thanks for your reply. First, you were right about my HibernateDAO. It
was not using the same credentials as the in-memory representation. In
fact the user that I was pulling back did not have any roles associated
with it that began with ROLE_. As soon as I added a fake role (ROLE_NONE)
I got the expected behavior that I was looking for with my HibernateDAO
object. An AccessDeniedException was thrown to the client which is what I
wanted instead of a 403 error. However, now I am a little confused about
how I am using this framework. Do I have to supply at least one role for
each principal so that role voting can work and throw this exception?
Also, I have the following configuration in my spring config file:
Hi Mark
The User object requires the GrantedAuthority[]s to be non-null. This is
just so we have a convenient place to ensure AuthenticationDaos are
creating valid objects.
The broader content of your email concerns the difference between
authentication and authorization. Basically a FilterSecurityInterceptor
or MethodSecurityInterceptor will check the ((SecureContext)
ContextHolder.getContext()).getAuthentication(), and if null, it will
consider a request unauthenticated and throw an AuthenticationException.
If an Authentication instance was returned, instead it will delegate to
an AccessDecisionManager, which typically iterates the
Authentication.getAuthority()s. If the Authentication does not have the
required GrantedAuthority, it will throw an AccessDeniedException.
Sitting at the filter level, the SecurityEnforcementFilter catches both
AccessDeniedException and AuthenticationException. If the latter, it
will delegate to an AuthenticationEntryPoint (which in BASIC
authentication will send a 401). If the former, it will call:
protected void sendAccessDeniedError(ServletRequest request,
ServletResponse response) throws IOException
The above method was added yesterday to assist fully controlling the
behaviour. The default implementation sends a SC_FORBIDDEN response (ie
code 403).
This approach is analogous to a typical web browser operating with BASIC
authentication. You visit a site, and hit a protected resource. You're
prompted to login. Then you move around the site and every access
decision is made based on that existing login. If you try to access a
resource for which you have no permissions, you get a 403 error message.
To resolve the 403, you'd need to logout (close your browser) and login
again with an appropriate account.
Not sure how all of this impacts you, but I hope this explanation of
behaviour helps.
Best regards
Ben
-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com
_______________________________________________
Acegisecurity-developer mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
