I'm trying to get my head around the various options for securing a struts 2 application. From my current research, it doesn't look like struts 2 provides any additional tools to help implement security models -- ie either you use the standard JAAS options at the web.xml level or you roll(integrate) your own security model. Am I missing any support built in?
I'm especially interested in fine-grain authorization tools, things like "does user X have permissions Y on resource Z". I stumbled across the "Security Annotation Framework" at sourceforge (projectname SAFR), which appears to be a solution to the problem, but it doesn't appear to be very active/alive.
I've also looked at various pieces of Spring AOP for providing this type of access-control, but don't see anything even remotely similar. But I assume I could roll my own with custom annotations and before advice, etc.
Have I just been missing some search terms or is it fair to say that the current Struts 2, or even Java in general, landscape on security matters is basically JAAS with/without home-grown extensions?
Struts - up through v1.1 anyway - didn't use JAAS as its security framework - it employed the J2EE container-based security system. Some, though not all, J2EE application servers provided security realms based on JAAS, but other systems for authentication and authorization were more common, including JDBC user/password/role tables, LDAP and 3d-party security servers.
CBS is useful for coarse-grained security - it's integrated into both the classes and the taglibs of basic JSP and Struts. However, sometimes you need more. In the case of the last set of systems I had to secure, I provided a custom Tomcat security realm module. For the bulk of the the application, it provided standard role-based container security, but I reserved a utility class that would convert the application user's J2EE identity object (the Principal) into an expanded object that could be queried for fine-grained control by application code and/or custom taglibs.
The downside to this is that such apps are not portable. By wrapping the specialized security objects in an abstraction, we minimized the trauma we'd go through if, for example, we decided to move the app from Tomcat to WebSphere, but there'd still be issues - one of which would be how to construct a whole new custom security framework for WebSphere that would replace the Security Realm we'd implemented for Tomcat.
The upside to this approach was that we minimized the specialized effects of our security. We could take third-party webapps and drop them in and no app customization would be required, since we supported CBS as a subset of our own, more fine-grained security system.
Customer surveys are for companies who didn't pay proper attention to begin with.