There are two three choices you have when assigning roles: (1) WebSphere Application Server authorization, in which authorization management is performed within the WebSphere Administration using the Security role to user/group mapping panel of the administrative console. (2) The System Authorization Facility (SAF) for role-based authorization (WebSphere Authorization Facility for z/OS only option) , which uses SAF authorization for Java 2 Platform Enterprise Edition (J2EE) roles. (3) External Authorization Provider using the pluggable JACC interfaces. When WebSphere Application Server is configured to use SAF Authorization, the authorization management is performed using SAF management facilities and the user or group to J2EE role Management within WebSphere Administration is ignored. SAF class of EJBROLE is used (for example, using the RACF EJBROLE profile) to control access by a client to Java 2 Platform, Enterprise Edition (J2EE) roles in EJB and Web applications, including the WebSphere Application Server administrative console application.
When using SAF authorization, to make sure that any changes in SAF to a User or group membership become effective, restart the server. Eventually WebSphere will become aware of the SAF changes, and they will become effective in WebSphere Application Server. When the changes become effective depends on the timing of cache refresh in the platform credential. It is often better to recycle each server address space as soon as possible to keep Websphere Application Server synchronized with your changes.
When SAF authorization is enabled, SAF EJBROLE profiles are used to authorize J2EE roles. For non-local operating system registries, identity mapping must be in place to map WebSphere Application Server identities to SAF identities.
To enable SAF authorization, see z/OS System Authorization Facility authorization for more information.
Defining EJBROLES belongs to the application deployment process. If the user ID has at least READ access to the defined EJBROLE profile that corresponds to the J2EE role defined by the application, the user ID is considered to be in Role. (Do not be confused by the name EJBROLE. It is used for J2EE roles in both enterprise beans and Web applications.)
When an application deployer uses a role in the deployment descriptor of a component, the role name must be identical to the name of an EJBROLE profile. A security administrator defines EJBROLE profiles and permits SAF users or groups to the profiles. In order to be considered as eligible for a role, a user must have read access to the EJBROLE profile or must be connected to a SAF group that has read access.
The specification of a security domain prefix affects the specific EJBROLE profiles used by WebSphere Application Server for z/OS system resources when SAF authorization is chosen. When SecurityDomainType=cellQualified, the J2EE application EJBROLE profiles for the WebSphere Application Server for z/OS runtime are done when a security domain prefix is also specified. This enables you to deploy the same application on different cells in the same sysplex, but have different user to role mappings if desired.
For example, your application has two J2EE role names: juniorTellers and seniorTellers. These are mixed case roles. In your SAF registry, you have an MVS group called JTELLER and STELLER and a MVS user ID called BANKADM. The JTELLER group is required to access to the juniorTellers role, and the STELLER group is required to access the seniorTellers role. The BANKADM user ID is required to access both roles.
You have two cells, both defined to use a security Domain prefix. The security domain names are PRODCELL and TESTCELL, respectively. The TEST1 user ID should have access to both roles, but only in the test environment TESTCELL.
If you wanted to deploy the same application in both cells, you must define distinct profiles using a RACF (or equivalent security subsystem) as follows.
/* the EJBROLE class must be active, this step is done by the customization dialogs */ SETROPTS CLASSACT(EJBROLE) /* first define the roles in RACF */ RDEFINE EJBROLE PRODCELL.juniorTellers UACC(NONE) RDEFINE EJBROLE PRODCELL.seniorTellers UACC(NONE) RDEFINE EJBROLE TESTCELL.juniorTellers UACC(NONE) RDEFINE EJBROLE TESTCELL.seniorTellers UACC(NONE) /* permit the appropriate users and groups to the various roles */ PERMIT PRODCELL.juniorTellers CLASS(EJBROLE) ID(JTELLER BANKADM) ACCESS(READ) PERMIT PRODCELL.seniorTellers CLASS(EJBROLE) ID(STELLER BANKADM) ACCESS(READ) PERMIT TESTCELL.juniorTellers CLASS(EJBROLE) ID(TEST1) ACCESS(READ) PERMIT TESTCELL.seniorTellers CLASS(EJBROLE) ID(TEST1) ACCESS(READ) /* refresh the EJBROLE class in RACF * SETROPTS RACLIST(EJBROLE) REFRESH"
Grouping EJBROLES (GEJBROLE)
The SAF interface also supports a grouping class for the EJBROLE class. This grouping class is called GEJBROLE. It is particularly useful when you have a need to give access to the same users or groups for several roles.
This following list explains the relationship between GEJBROLES, EJBROLES and EJBROLES within the GEJBROLE (ADDMEM).