Authorization in JEE

Most articles on JAAS seem to be centered on Authentication, and having a byline on Authorization, or none at all. Refer to All that JAAS as an example. This is not a criticism of that article, it just shows how Authorization is ignored in most discussions on application security. You will notice this mostly when you try to explain to managers that User Interface Optimization is not a part of authorization or when you try to explain someone what "Instance based Authorization" means. So, it is refreshing to see a new article on Application Authorization alone. The new article on Developerworks titled "Authorization concepts and solutions for J2EE applications" discusses few basic authorization patterns and the state of authorization technology in the Java EE space. Here is a brief summary:

Authorization Patterns

• Role based authorization: Role-based authorization provides access to resources based on the fact that the user is assigned a Role in the application. A "Role" can be defined as a class of users with similar access to the application's functionality. Roles are determined based on a user's group memberships as defined in a user registry. This type of authorization is the standard of the JEE world. It is a coarse-grained form of access control generally defined by URLs or EJB method calls, as defined in the Web and EJB deployment descriptors, or by the use of the getCallerPrincipal() and isCallerInRole() methods available in EJBContext. It is important to note that a Role is different from Groups defined in a User registry. A role is defined by the application functionality, while a group is defined by the organizational hierarchy.
• Instance based Authorization: This pattern provides a more granular level of authorization than is typically provided by J2EE role-based authorization, getting down to the level of an individual object (an particular instance of an EJB, so to speak) within a system. In this case, we are controlling access based on the EJB methods invoked, as well as the arguments passed to them. Instance-based authorization typically protects instances using access control lists (ACLs), which are stored in some type of policy store and can be used to make access decisions. The best way to implement this type solution is through the use of an external security manager, such as IBM's Tivoli Access Manager.
• Ownership relationships: It is a specific case of the instance-based pattern where there is an owner relationship within the data structures of the application between the user and some other protected data. This typically means that the authorization rules have to be embedded into the data access logic of the application itself. One such example would be to present a user with a list of results that are owned by him. In such cases, a the request to the database must contain the user information for filtering the results. Filtering results in the application is inefficient, particulary when results are shown in multiple pages, in which case a single page display may require multiple requests to database. Stored procedures may be optimal places to apply authorization rules for some applications.
• User Interface customization: The dynamic modification of a user interface to only show actions that the user is entitled to perform is often regarded as an aspect of authorization. But is does not constitute authorization as a whole, since web requests can be modified at the client side too.