Catching an AccessDeniedAcception

[adrianmrossi]

Hi,

This may be a stupid question (I hope not!)....but I have Acegi setup and working very well accept for one small issue...when a user attempts to access a page (I am also using Tapestry, just FYI) and they do not have access permissions then the AccessDecisionManager throws (correctly) an AccessDeniedException. My question is this- how do I catch this exception in my application? I want to be able to redirect the client to the login page, but instead I get an exception occured error (which it did) in my browser(!)

How do I catch the exception (that is where can I insert a try/catch block for it) so I can programmatically redirect to the Login page?

Thanks!

-Adrian

[Ben Alex]

In MVC applications we address this using SecurityEnforcementFilter, which catches the underlying AccessDeniedException and converts it to a 403 SC_FORBIDDEN response. Not sure if this approach is directly usable with Tapestry.

[adrianmrossi]

Hi Ben,

Firstly, thanks for your response!

OK I have some further questions then...

If SecurityEnforcementFilter catches the exception how do I configure it to react differently then the standard mechanism you describe? The issue with Tapestry is that it does not use the web.xml error page configuraiton so when excpetions are thrown (e.g. 403) they are not intercepted (as far as I can tell) by the container (Tomcat 5.5 in my case.) This means that these exceptions need to ba handled in the application code (i.e. the Acegi code) otherwise they are simply displayed in the client browser which is ugly. I want to redirect to a login page whenever an AccessDeniedException is thrown. Do I need to modify the source code or can this be achieved through the context config file?

Another related issue is what happens after authentication. The current configuration allows a redirect to a defaultUrl but this isnot flexible enough. I want to redirect to any page of my choosing based on the user's credentials (e.g. username).

I had to go into the AbstractProcessingFilter and add code which sets the TargetURL to the correct destination page basedon credentials.

My questions are (1) is this a good approach (can it be done through currect configuration parameters) (2) is this the right place to add code (by the way it works like a charm!).

I was thinking of actually creating a new Spring bean service for Acegi which reads in elements from the context XML file so that i can relate Roles to home pages (e.g. ROLE_ANONYMOUS --> Anon_Home.html, ROLE_MANAGER --> Man_Home.html, etc.). That way all such configuration is co-located with the ROLE definitions elements in the context file.

What do you think?

Thanks! And by the way Acegi is fantastic, light-years ahead of J2EE security. :-) (We are using it along with Spring, Tapestry and Hibernate in our project.)


-Adrian

[Ben Alex]

I want to redirect to a login page whenever an AccessDeniedException is thrown. Do I need to modify the source code or can this be achieved through the context config file?

You can subclass SecurityEnforcementFilter and override its various protected methods to fine-tune behaviour, such as the sendAccessDeniedException() method or sendStartAuthenticationMethod().

Another related issue is what happens after authentication. The current configuration allows a redirect to a defaultUrl but this isnot flexible enough. I want to redirect to any page of my choosing based on the user's credentials (e.g. username).

Instead of modifying AbstractProcessingFilter, I would suggest you write your own AuthenticationEntryPoint. It would be similar to AuthenticationProcessingFilterEntryPoint, but would be able to introspect the Authentication details and then adjust the target URL put into the HttpSession.

I was thinking of actually creating a new Spring bean service for Acegi which reads in elements from the context XML file so that i can relate Roles to home pages (e.g. ROLE_ANONYMOUS --> Anon_Home.html, ROLE_MANAGER --> Man_Home.html, etc.). That way all such configuration is co-located with the ROLE definitions elements in the context file.

You could do this, although having access to roles indicates the principal has already authenticated so I presume this discussion applies to your custom handling of AccessDeniedException (as distinct from AuthenticationExceptions, which are handled by delegation to the AuthenticationEntryPoint). You could access the currently logged on principal via the ContextHolder in your SecurityEnforcementFilter subclass in that method.

[adrianmrossi]

Perfect - thanks Ben for your advice. Got what I need now...:-)

Cheers,

-Adrian