Thursday, November 20, 2008

Page-Level Access Controls in Struts 2 - Part 1


Applications should ensure users are properly authenticated and have sufficient permissions to access pages before content is displayed. Page-level access controls are one security control that enforces this behavior.

Part 1 and 2 of this article describes one of many ways to implement a Struts 2 AuthenticationInterceptor and a RolesInterceptor to verify users have authenticated successfully and belong to an approved role before allowing access to pages. The key features targeted by both interceptors include a default deny policy and a centralized location for defining access control rules.

Struts 2 AuthenticationInterceptor

In the struts.xml file below, the AuthenticationInterceptor is defined and included in the defaultSecurityStackWithAuthentication. The "excludeActions" parameter provided to the interceptor lists the actions that do not require users to be authenticated. In this case, the "Login" and "ProcessSimpleLogin" actions do not require authentication, however the "Internal" page does require authentication.


(Click the image above to view the XML)

When the AuthenticationInterceptor is called, the interceptor verifies the requested action is in the exclude list or the user has the "authenticated" session variable set to "True."


(Click the image above to view the code)

Finally, to allow users access to authenticated pages, the ProcessSimpleLogin action verifies the submitted credentials and then sets the "authenticated" session variable to "True."


(Click the image above to view the code)

The code repository containing updated struts 2 modules can be found below:

Additionally, you can see discussion of these modules in my earlier blog posts:


Anonymous said...

I like your example & am doing something similar. I don't see AuthenticationAware as an object in my struts2 project though. What jar is it in? I don't see RolesAware either.

Nick Coblentz said...

AuthenticationAware and RolesAware are custom classes I wrote myself. They were intended to allow an interceptor to inject information into the action regarding whether the user was authenticated and which roles they had been granted.

I didn't end up utilizing this functionality, so I should have removed that code before I published the article. Sorry for the confusion.