How to apply Authorization in a Web Application?

This is a classic problem which programmers would face when building an enterprise application. Given a number of users, roles, modules, and actions, a programmer should find a way to check the authorization of a user upon performing an action. On a quasi-secure approach, we could provide different menu for each role. But this way, a user could easily type the URI directly and received no proper authorization.

I've been exploring some solutions to this problem and so far, I've found three alternatives.


1. Add authorization code in every single Struts action

This alternative is obtrusive and nonmodular and nonpluggable. It means, while this way could offer a straightforward solution, it provides no flexibility in object-oriented paradigm.

2. Apply interceptors

This is the first non-obtrusive solution that I can think of, due to my experience in building web applications with WebWork. Sadly, Struts offers no such thing as interceptor. However, I found How to get better handle of Struts actions with Spring which offers several methods. The writer suggested  by creating a proxy class for every struts action, which in turn will be treated as Spring action. With those Struts actions 'treated' as Spring actions, applying Spring interceptors would be easy. This sounds very applicable in our context, but after a few tries of implementing it, I backed off, trying to get a simpler solution.

3. Apply servlet filter to URI

When I browsed an article about Design Pattern, I stumbled over an interesting part which say that Servlet Filter is a form of Interceptor Pattern. With lots of examples,  creating an authorization filter is easy. There are several ways to implement the filter in our application. (a) By creating a spesific filter for each role, and apply each filter to certain URI patterns. For example I could create AdminSecurityFilter and then apply it to /admin/* and CashierSecurityFilter to /payment/*. While easing the configuration of URI patterns (which could easily be done by altering web.xml), this way offers little flexibility upon adding a new role. New filter should be written everytime a new role is added to the application. To achieve greater flexibility, (b) there should be only one filter, applied to all URIs. However, the filter should use a component which check out the authorization based on user roles and URI.