Monthly Archives: September 2008

In part 2 we outlined the annotations and enums were going to use to store our permission data. Applying a permission annotation to a dispatch method looks like this. @Permissions(operation = Operation.OR, permissions = { @Permission(permissionKey = RequiredPermissions.VIEW_INVENTORY, permissionType = … Continue reading →

The code below is a much simplified approximation of the solution we came up with, so this is essentially pseudo code but should define the model close enough. First we will need to define multiple annotations interfaces, the first one … Continue reading →

I recently implemented a server side security mechanism for performing permission checks in Struts using Java 5 annotations. My company (Uplogix) manufactures a linux based appliance which performs secure remote management of large and geographically disperse networks. We have a web application that acts as a central point of configuration for our distributed appliances. Part of our solution entails a rather granular form of authorization that allows administrators to lock down or allow access to very specific components of our web application.

Without getting into too much detail our security model allows you to grants or deny specific permissions (i.e. allow/deny CONFIGURE_FOO, VIEW_FOO). These permissions can be granted on a user or group level (users can be members of multiple groups), and when a user attempts to view a specific page a permission check must be executed against the users context, and an appliance or server context (the device or groups of devices you are attempting to configure). Many pages have complex AND, OR, AND/OR permission checks, for example a user may view a page if they have the CONFIGURE_FOO || VIEW_FOO permissions. And several pages have “trump” type permissions such that a user may view this page is they have for example (PERMISSION_1 && PERMISSION_2) || TRUMP_PERMISSION)

Our web application uses both Struts 1 and Struts 2 but when I implemented the solution we were only using Struts 1. The solution will work well with our Struts 2 implementation so there’s no need to refactor any code as we move to Struts 2. Initially I considered using a Servlet filter but I found this annotation based solution to be as good, if not better then a filter for a few reasons.

• The annotations are compiled checked just like a Servlet filter.
• We can attach the logic for the particular permission directly on the method in question (in our case a Struts dispatch). This allows the developer to see permission check right on the method while refactoring, rather then having to go searching for it in another class
• The permission logic is easily readable by a human and you don’t need to interpret if/else logic in Java that would be required if the implementation were done in a Servlet Filter
• Our permission model is complex and there are 100′s of potential permission checks. Using a servlet filter I would have had to push all of this logic into a large Map with a key/value pair of method name (or “dispatch” in Struts terminology) to “permission check”. This Map would have quickly grown to an unruly size in the code. Further if a method were renamed the Map would have to be updated manually to reflect this change. I experimented with writing a process that was called within the build.xml to determine any methods were missing permissions checks, but found this to be a fragile solution and it only served to validate the annotations model I will discuss shortly

Continue reading →