Role-based authorization
Use authorization information to determine whether a caller has the necessary privileges to request a service.
The following figure illustrates the process that is used during authorization.

Web resource access from a web client is handled by a web collaborator. The Enterprise JavaBeans (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 resource permission module helps determine the required roles for a given resource. This module uses a resource-to-roles mapping table that is built by the security runtime during application startup. To build the resource-to-role mapping table, the security runtime reads the deployment descriptor of the enterprise beans or the Web module (ejb-jar.xml file or web.xml file)
- The authorization table module consults a role-to-user or group
table to determine whether a client is granted one of the required
roles. The role-to-user or group mapping table, also known as the
authorization table, is created by the security runtime during application
startup.
To build the authorization table, the security run time reads the application binding file, the ibm-application-bnd.xmi file, or the ibm-application-bnd.xml file, as appropriate.
The authorization table can also be built when accessing the EJBROLE profiles at the time of authorization using the Security Access Facility (such as RACF®).
支援的配置: 對於 IBM® 延伸和連結檔而言,.xmi 或 .xml 副檔名取決於您是使用 Java EE 5 之前的應用程式或模組,或 Java EE 5 或更新版本的應用程式或模組。 IBM 延伸或連結檔稱為 ibm-*-ext.xmi 或 ibm-*-bnd.xmi,其中 * 是延伸或連結檔的類型,例如:app、application、ejb-jar 或 web。 適用的條件如下:
不過,即使應用程式含有 Java EE 5 之前的檔案,且所用的副檔名是 .xmi,其中也可以有 Java EE 5 或更新版本的模組。
ibm-webservices-ext.xmi、ibm-webservices-bnd.xmi、ibm-webservicesclient-bnd.xmi、ibm-webservicesclient-ext.xmi 和 ibm-portlet-ext.xmi 檔會繼續使用 .xmi 副檔名。
sptcfg
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 Platform, Enterprise Edition (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 that are 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.
- The AllAuthenticatedUsers subject 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.
- The AllAuthenticatedInTrustedRealms subject permits all authenticated foreign users (those that are bound to other realms) to access protected methods. As long as the user can authenticate successfully, the user is permitted access to the protected resource.
- The Everyone subject 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 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 that are granted to that role.
Depending on your 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.
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.
The administrator is
responsible for managing these roles.
Users can be assigned to more than one role; the permissions that are 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.
![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
![[IBM i]](../images/iseries.gif)
- Improves performance during the authorization check. Typically far fewer groups exist than users.
- Provides greater flexibility, by 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 Application Server roles. Stop and restart the enterprise application for these changes to take effect. This action can be very disruptive in a production environment.
A best practice during
deployment is to assign groups instead of 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. For further information,
see System Authorization
Facility for role-based authorization
At runtime, 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 run a method, the request is authorized. If the user does not belong to any role that has permission, the request is denied.
- getCallerPrincipal: This method retrieves the user identification information.
- isCallerInRole: This method checks the user identification information against a specific role.
- 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