Use authorization information to determine whether a caller has the necessary privileges to request a service.
The following figure illustrates the process during authorization. Web resource access from a Web client is handled by a Web collaborator. The EJB resource access from a Java client (can be enterprise beans or a servlet) is handled by an EJB Collaborator. The resource and the received credentials are presented to WSAccessManager to check whether access is permitted to the client to access the requested resource.
The access manager module contains two main modules:
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 uses the Java 2 Enterprise Edition (J2EE) authorization model. In this model, authorization information is organized as follows:
There are two special subjects that are not defined by J2EE, but are worth understanding: AllAuthenticatedUsers and Everyone. (These special subjects are not available if you choose SAF as your authorization mechanism.) 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.
Note: When SAF is used, this function is simulated by the definition of the unauthenticated user ID in RACF with RESTRICTED property. If an EJBROLE profile is created with Universal Access (UACC) of READ, all authenticated users have access except the unauthenticated user ID.
During the deployment of an application, real users or groups of users are assigned to the roles. The system deployer (or administrator) 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. If you are using bindings rather than SAF EJBRoles for authorization and you need to change the binding value, you must restart the server to pick up new values. If you are using SAF EJBRoles, the application server automatically detects the changes.
At run time, WebSphere Application Server 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 Enterprise JavaBeans, the following two methods are supported by WebSphere Application Server:
For servlets, the following methods are supported by WebSphere Application Server:
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