+

Search Tips   |   Advanced Search

Role-based authorization

Use authorization information to determine whether a caller has the necessary privileges to request a service.

Web resource access from a web client is handled by a web collaborator. The EJB resource access from a Java client, whether an enterprise bean or a servlet, is handled by an EJB collaborator. The EJB collaborator and the web collaborator extract 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 WSAccessManager access manager to check whether access is permitted to the client for accessing 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. We can store authorization information many ways. For example, with each resource, we 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 J2EE authorization model. In this model, authorization information is organized as follows:

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: AllAuthenticatedUsers, AllAuthenticatedInTrustedRealms, and Everyone. A special subject is a product-defined entity that is defined outside of the user registry. This entity is used to generically represent a class of users or groups in the registry.

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.

(ZOS) When WAS is configured using SAF, special subjects are ignored. These functions are available within SAF. The functions are simulated by the definition of the unauthenticated user ID in RACF with a RESTRICTED property. If an EJBROLE profile is created with a Universal Access (UACC) of READ, all authenticated users have access with the exception of the unauthenticated user ID.

(ZOS) Depending on the environment, some restrictions might exist. For example, when utilizing SAF, checks are always made against the SAF database. If authentication is not done before an access check against a given role starts, a default SAF identity is used for the check. Unless a valid default user ID is configured in the com.ibm.SAF.authorization property, access is not granted.

(ZOS) The administrator is responsible for managing these roles.

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:

(ZOS) A best practice during deployment is to assign groups instead of individual users to roles. If we are using bindings rather than SAF EJBROLES for authorization and we need to change the binding value, we must restart the server to pick up new values. If we are using SAF EJBROLES, the application server automatically detects the changes. For further information, see System Authorization Facility for role-based authorization

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 that 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:

For servlets, the following methods are supported by WAS:

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