Role-based authorization
Authorization information determines whether a caller has the necessary privileges to request a service. Web resource access from a web client is handled by a web collaborator. EJB resource access from a Java client is handled by an EJB collaborator. Both collaborators extract the client credentials from the current object request broker (ORB) object. Client credentials are set during the authentication process and are presented to the WSAccessManager access manager, which checks whether access is permitted to the client for the requested resource.
The access manager module contains two main modules:
Module Description Resource permission Reads a resource-to-roles mapping table to determine roles for a given resource. The table is built during application startup by the security runtime which reads the deployment descriptor of the enterprise beans or the Web module (ejb-jar.xml or web.xml) Authorization table Reads a role-to-user or group table to determine whether a client is granted one of the required roles. This table is built during application startup by the security run time which reads the application binding file (ibm-application-bnd.xmi or ibm-application-bnd.xml). For applications using Java EE version prior to v5, the file extension must be .xmi. For applications using Java EE 5 or later, the file extension must be .xml.
A Java EE 5 or later module can exist within an application that includes pre-Java EE 5 files and uses the .xmi file name extension. The following files continue to use the .xmi file extensions:
- ibm-webservices-ext.xmi
- ibm-webservices-bnd.xmi
- ibm-webservicesclient-bnd.xmi
- ibm-webservicesclient-ext.xmi
- ibm-portlet-ext.xmi
Authorization information can be stored in a variety of ways. We can store an access-control list, which contains a list of users and user privileges. We can associate a list of resources and the corresponding privileges with each user (Capability list).
WebSphere Application Server uses the J2EE authorization model. During the assembly of an application, permission to invoke methods is granted to one or more roles. A role is a set of permissions; for example, in a banking application, roles can include teller, supervisor, clerk, and other industry-related positions. The teller role is associated with permissions to run methods related to managing the money in an account, such as the withdraw and deposit methods. The teller role is not granted permission to close accounts; this permission is given to the supervisor role. The application assembler defines a list of method permissions for each role. This list is stored in the deployment descriptor for the application. With Java EE7 and later, a special role name "**" is introduced. This role indicates that the access is granted when a user is authenticated.
Three special subjects are not defined by the J2EE model. A special subject is a product-defined entity defined outside of the user registry. This entity is used to generically represent a class of users or groups in the registry.
AllAuthenticatedUsers Authenticated users can protected methods. AllAuthenticatedInTrustedRealms Authenticated foreign users (those that are bound to other realms) can access protected methods. Everyone Unrestricted access to a protected resource. Users do not have to authenticate to get access; this special subject provides access to protected methods as if the resources are unprotected.
During the deployment of an application, real users or groups of users are assigned to the roles. When a user is assigned to a role, the user gets all the method permissions granted to that role. The application deployer does not need to understand the individual methods. By assigning roles to methods, the application assembler simplifies the job of the application deployer. Instead of working with a set of methods, the deployer works with the roles, which represent semantic groupings of the methods.
Users can be assigned to more than one role; the permissions granted to the user are the union of the permissions granted to each role. Additionally, if the authentication mechanism supports the grouping of users, these groups can be assigned to roles. Assigning a group to a role has the same effect as assigning each individual user to the role.
A best practice during deployment is to assign groups instead of individual users to roles for the following reasons:
- Improves performance during the authorization check. Typically far fewer groups exist than users.
- Provides greater flexibility, using group membership to control resource access.
- Supports the addition and deletion of users from groups outside of the product environment. This action is preferred to adding and removing them to WebSphere roles. Stop and restart the enterprise application for these changes to take effect. This action can be very disruptive in a production environment.
At runtime, WAS authorizes incoming requests based on the user's identification information and the mapping of the user to roles. If the user belongs to any role that has permission to run a method, the request is authorized. If the user does not belong to any role that has permission, the request is denied.
The J2EE approach represents a declarative approach to authorization, but it also recognizes we cannot deal with all situations declaratively. For these situations, methods are provided for determining user and role information programmatically. For enterprise beans, the following two methods are supported by WAS:
- getCallerPrincipal: This method retrieves the user identification information.
- isCallerInRole: This method checks the user identification information against a specific role.
For servlets, the following methods are supported by WAS:
- getRemoteUser
- isUserInRole
- getUserPrincipal
These methods correspond in purpose to the enterprise bean methods.
For more information on the J2EE security authorization model, see the following website: http://java.sun.com
Related:
Authorization technology Servlet security methods Assign users and groups to roles