- 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
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.