There are 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.
Important considerations when using SAF authorization: When you select SAF for authorization, there are several
functional implications to subsequent authorization operations that
you need to consider:
- If SAF authorization is selected on the administrative console,
it overrides any other authorization choice (such as, Tivoli Access
Manager authorization). See Summary of controls for
more information.
- When SAF authorization is enabled, authorization on any level
is always performed by the operating system's security manager (RACF
or equivalent product). That is, users need to be authenticated with
a security manager (RACF) user ID or a SAF mapping module needs to
be used.. See System Authorization Facility considerations for the operating system and application levels for more information.
- When SAF authorization is selected during systems customization,
administrative EJBROLE profiles for all administrative roles are defined
by the RACF jobs generated using the customization dialogs, and SAF
authorization can be used as an authorization mechanism for all user
registries. See Controlling access to console users when using a Local OS Registry for more
information.
- When configuring SAF authorization, property, com.ibm.security.SAF.authorization is
set to true and SAF EJBROLE profiles are used to
control access to administrative roles. See Authorizing access to administrative roles for more information about authorizing
access to administrative roles.
- When SAF authorization is enabled, any values in the console users
and console groups are ignored. The Map security roles to users/groups
functional panel in the administrative console is ignored. See Administrative roles and naming service authorization for more information.
- Everyone and All Authenticated are ignored since they are managed
in RACF. See System Authorization Facility considerations for the operating system and application levels as well as Security role to user or group mapping for more information.
- When SAF authorization is enabled, the SAF EJBROLE profiles are
used to control access to CosNaming functions. During security domain
setup in the customization dialog, the CosNaming roles are defined
by customization jobs. See Special considerations for controlling access to naming roles using SAF authorization for
more information on CosNaming functions and SAF authorization as well
as referencing Administrative roles and naming service authorization.
- 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. See Controlling access to console users when using a Local OS Registry for
more information
- SAF authorization for J2EE roles is a task that is independent
of the application deployment process. See Assigning users and groups to roles for more information.
- The EJBROLE class should be RACLISTed. If the EJBROLE class is
not RACLISTed, you must restart the application server to pick up
changes made to profiles in the EJBROLE class.
Supported configurations: When you use SAF authorization,
to make sure that any changes in SAF to a user or group membership
become effective immediately, call the purgeUserFromAuthCache SecurityAdmin
mbean method for the modified user. Otherwise, the changes become
effective when the cache is refreshed on a periodic basis. As an alternative,
you can restart the server.
sptcfg
When SAF authorization is enabled, SAF EJBROLE profiles are used
to authorize Java EE 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 Java EE
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 Java EE 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 SAF profile prefix (previously referred
to as a z/OS® security domain) affects the specific EJBROLE
profiles used by WebSphere Application Server for z/OS system
resources when SAF authorization is chosen. When a SAF prefix is defined,
the Java EE application EJBROLE profiles for the WebSphere Application Server for z/OS runtime
are prefixed with the value of this property. 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 Java EE
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 SAF profile prefix.
The prefixes 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.
If RACF is used as your security server, enable
this by issuing the following commands:
/* 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.
The GEJBROLE grouping class provides a capability not natively
available in other Java EE servers. Using the Java EE security model, if there are several
components or applications that use different role names for similar
functions, such as Hire, Promote, or GrantPayraise for managerial
functions, there are several options:
- Adjust the application deployment descriptors so that they conform
to the roles already defined in the enterprise, such as managers.
This process is time consuming and error prone especially because
it might require a readjustment of the deployment descriptor each
time the application is changed or reinstalled.
- Define the EJBROLE profiles for each of the roles that are required
by the application. Then, permit users and groups to access these
roles. This process might be extensive for the administrator because
the same users and groups might have permissions for several different
profiles with similar meanings.
- Use the grouping class to avoid the worst issues with the other
two options. You must still define EJBROLE profiles for each of the
roles required by the application. Instead of permitting all of the
same users and groups to use the new profiles, create a profile, such
as supervisors, in the grouping class and add all of the new EJBROLE
profiles to it. You can give permission in one place to every user
and group that needs access to these roles, such as the supervisors
profile. You can further avoid administrative work by adding the existing
EJBROLE profile (Managers) to the grouping class profile (Supervisors).
Considerations when implementing GEJBROLES:
- Plan organizational role profiles in the RACF class
GEJBROLEs.
- Create the access list by permitting user groups to the GEJBROLE
profiles, then add roles to the GEJBROLE profiles.
- A GEJBROLE with only one EJBROLE is OK.
- Do not use a mixture of EJBROLE and GEJBROLE for permitting users
to roles.
- If possible, permit users to GEJBROLE profiles only.
- Generally use GEJBROLE in preference to EJBROLE.