Re: [Acegisecurity-developer] Re: AccessDeniedException

2004-08-04 Thread Ben Alex
[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


[Acegisecurity-developer] Re: AccessDeniedException

2004-08-02 Thread Ben Alex
[EMAIL PROTECTED] wrote:
Ben,
I am still having problems getting messages to the forum...  Anyways, here
is my latest issue if you could please put it into the forum ,and maybe
give advise ;).
---
I am having a problem when using basic authentication and my own
authentication DAO implementation.  I am attempting to interface using
Hibernate to the database for authentication which works fine.  I was
using an InMemoryDaoImpl to do testing with.  The InMemoryDaoImpl allows
me to authenticate correctly and when the user did not have the required
role an AccessDeniedException would be thrown and I could handle this no
problem.  When I switched to the Hibernate DAO implementation I can
authenticate no problem, but when access could not be granted to a
resource I got a 403 HTTP error.  I really wanted my custom DAO
implementation to react the same as the InMemoryDAOImpl and throw the
AccessDeniedException.
 

I'm not sure why this is happening. Both DAOs should simply provide a 
UserDetails to the DaoAuthenticationProvider, which constructs an 
Authentication object if a valid authentication request was received. 
Therefore there should be no difference at the authorization stage, 
unless the created Authentication object is different. I'm tipping your 
Hibernate DAO implementation is not adding the same GrantedAuthority[]s 
to the UserDetails as the InMemoryDaoImpl is. I'd add some logging to 
your Hibernate DAO to see what the returned UserDetails actually contains.

I tried to subclass
net.sf.acegisecurity.intercept.web.SecurityEnforcementFilter such that it
would throw an AccessDeniedException instead of returning a 403, however
this did not work.  I replaced the securityEnforcement filter to use the
subclass that I created and updated the web.xml to use this as well.  Any
suggestions to use the AccessDeniedException using basic authentication
would be appreciated.  I need to this because I am using a Flash client
and I need to handle an exception/fault at this time instead of an HTTP
error code.
 

403 gets sent in the event of an AccessDeniedException. Alternatively, 
if it's an AuthenticationException, the AuthenticationEntryPoint gets 
commenced. You'll probably use BasicProcessingFilterEntryPoint which 
sends a 401 to request the browser to retry with a BASIC authentication 
header.

I'm really thinking your Hibernate DAO is simply failing to populate the 
GrantedAuthority[]s of the UserDetails implementation (in most cases 
User), which is why you're getting AccessDeniedExceptions in the first 
place. However, I've just checked in a change to 
SecurityEnforcementFilter so there is a sendAccessDeniedError protected 
method you can override in a subclass if required.

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