Use authorization information to determine whether a caller has the necessary privileges to request a service.
The following figure illustrates the process used during authorization. Web resource access from a Web client is handled by a Web collaborator. The Web collaborator extracts the client credentials from the object request broker (ORB) current object. The client credentials are set during the authentication process as received credentials in the ORB current object. The resource and the received credentials are presented to the access manager module to check whether access is permitted to the client for accessing the requested resource.
The access manager module contains two main modules:
Resource permission module helps determine the required roles for a given resource. It uses a resource to roles mapping table that is built by the security run time during application startup. To build the resource-to-role mapping table, the security run time reads the deployment descriptor of the Web module (the web.xml file).
Authorization table module determines whether a client is granted one of the required roles by consulting a table that maps roles to users or groups. The mapping table, also known as the authorization table, is created by the security run time during application startup. To build the authorization table, the security run time reads the application binding file (the ibm-application-bnd.xmi file).
Figure 1: Authentication
Use authorization information to determine whether a caller has the necessary privilege to request a service. You can store authorization information many ways. For example, with each resource, you can store an access-control list, which contains a list of users and user privileges. Another way to store the information is to associate a list of resources and the corresponding privileges with each user. This list is called a capability list.
WebSphere Application Server - Express uses the Java 2 Enterprise Edition (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.
A special subject is a product-defined entity independent of the user registry. It is used to generically represent a class of users or groups in the registry. There are two special subjects that are not defined by J2EE but that are provided by WebSphere Application Server - Express:
AllAuthenticatedUsers is a special subject that permits all authenticated users to access protected methods. As long as the user can authenticate successfully, the user is permitted access to the protected resource.
Everyone is a special subject that permits 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 were unprotected.
During the deployment of an application, real users or groups of users are assigned to the roles. 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. When a user is assigned to a role, the user gets all the method permissions that are granted to that role. 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, rather than individual users, to roles for the following reasons:
At run time, WebSphere Application Server - Express 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 execute 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 that you cannot deal with all situations declaratively. For these situations, methods are provided for determining user and role information programmatically.
For servlets, the following methods are supported by WebSphere Application Server - Express:
getRemoteUser()
This method retrieves the user name of the authenticated user.
isUserInRole()
This method checks the user identification information against a specific role.
getUserPrincipal()
This method retrieves the user identification information.
These methods correspond in purpose to the enterprise bean methods.
For more information on the J2EE security authorization model see the following Web site: http://java.sun.com 