+

Search Tips   |   Advanced Search

(zos)

System Authorization Facility classes and profiles

When using Resource Access Control Facility (RACF ) or System Authorization Facility (SAF) you must consider:

  1. Use roles for enterprise beans and web applications, and servlets

  2. Use RACF class profiles

    1. Use CBIND to access servers and objects in the servers

    2. Use SERVER to access controllers using servant regions

    3. Use STARTED to associate user IDs and groups with started procedures

    4. Use APPL to restrict access of authenticated users to applications in the server

    5. Use FACILITY to establish permission to enable Synch to OS Thread Allowed and allow mapping of distributed identities to SAF identities using the JAAS mapping login modules.

    6. Use SURROGAT to optionally establish permission to enable Synch to OS Thread Allowed

  3. Create multiple security configurations within a sysplex

  4. Generating new user IDs and Profiles for a new server

  5. Use minimalist profiles

Roles for Enterprise JavaBeans and web applications, and servlets

Roles are associated with Java EE applications. Modules within the applications refer to roles using the role reference that points to the application role. Access to web applications, servlets, or EJB methods is based upon the user or caller. Roles are associated with web applications, and servlets or enterprise beans at assembly time. The role needed to use a servlet or EJB method is named in the application's deployment descriptors.

Which users and groups have which roles is determined using RACF profiles in the EJBROLE class (if SAF authorization is selected). If a user is in the access list of an EJBROLE profile, the user has that role. If a group is in the access list of an EJBROLE profile, users in that group have that role. If the EJBROLE profile has ACCESS(READ), all users have that role.

The SAF profile prefix (previously referred to as z/OS security domain), if specified, becomes a prefix used by WebSphere Application Server for z/OS and RACF when checking EJBROLE profiles. This provides WebSphere SAF profile prefix-level granularity of roles.

For example: 

Test
Cell has Security Domain=TEST Production Cell has Security Domain=PROD

For example, an application using role Clerk is deployed on both cells. On the test cell, users need READ access to the EJBROLE profile TEST.Clerk. On the production cell, users need READ access to the EJBROLE profile PROD.Clerk.

The following profiles are defined in the RACF EJBROLE class for administrative authorization: administrator, configurator, monitor, operator, deployer, adminsecuritymanager, and auditor.

Refer to System Authorization Facility for role-based authorization for more information on how SAF can be used for Java EE-based role authorization.

Use the RACF profiles

It is important to understand the security mechanisms used to protect the server resources using the CBIND, SERVER, and STARTED classes in RACF (or the equivalent security product). We must also understand the techniques for managing the security environment.

The RACF profiles that protect the WAS for z/OS resources use the following classes:

  1. CBIND: Use this class to access to servers, and access to objects in the servers

  2. SERVER: Use this class to access to controllers by servant regions

  3. STARTED: Use this class to associate user IDs and groups to started procedures

  4. APPL: Use this class to restrict access of authenticated users to applications running on the server

  5. FACILITY: Use this class to:

    • associate user IDs and groups to the Synch to OS Thread Allowed option

    • control which security configurations are allowed to map distributed identities to SAF identities using the JAAS mapping login modules

  6. SURROGAT: Use this optional class to associate user IDs and groups to the Synch to OS Thread Allowed option
Refer to System Authorization Facility considerations for the operating system and application levels for more information.

Basic information about the RACF profiles used by WebSphere Application Server for z/OS can be found in the SAF-based authorization. This section adds some additional details about the CBIND, SERVER, FACILITY, SURROGAT, and STARTED class profiles.

User IDs and Group IDs

When creating a profile for an application server, the BBOCBRAK job generates the RACF commands. When creating a profile for a cell, deployment manager, job manager, or admin agent, the job name is BBODBRAJ. When creating a profile for a custom node, the job name is BBOMBRAJ. Enter the following information: 

CR = Controller Region SR = Servant
Region CFG = Configuration (group) server = server short name cluster = generic
server (short) name (also called cluster transition name)

Six users and six groups, defined as follows, are shown symbolically to help understand how they are used in the various permissions later on:

The following are the various profiles used to protect the WAS for z/OS resources, along with the permissions and access levels.

Use CBIND class profiles

There are two formats and levels of CBIND class profiles for protecting access to application servers and objects in those servers: 

CBIND Class profiles - access to generic servers CB.BIND.<cluster> UACC(READ); PERMIT <CR_group> ACC(CONTROL)
CBIND Class profiles - access to objects in servers CB.<cluster> UACC(READ) PERMIT <CR_group> ACC(CONTROL)

If we are using "SAF profile prefix", the CBIND profiles are qualified by the "profilePrefix" as follows:

CBIND profiles control access to WebSphere Application Server for z/OS servers, including web servers running the WAS plug-in, and to objects in the servers, from Java application clients and other WebSphere Application Server servers. For access to servers, enter: 

CB.CBIND.<cluster>
CB.CBIND.<SAF profile prefix>.<cluster>

For access to objects within servers, enter:

Use SERVER class profiles

There are currently two formats of the SERVER class profiles for protecting access to the server controllers. 

SERVER
class profiles - access to controllers using static Application Environments
 CB.server.<cluster>   UACC(NONE) PERMIT <SR_userid> ACC(READ)
             SERVER class profiles - access to controllers using dynamic Application Environments  CB.server.<cluster>.<cell> UACC(NONE) PERMIT <SR_userid>
ACC(READ)

In using the WebSphere z/OS Profile Management Tool or the zpmt, both formats are predefined, and one of these is actually required at runtime. The required format is determined dynamically by the WAS for z/OS Runtime based on the availability of Dynamic Application Environment (DAE) support. The following command provides access to controllers using static Application Environments: 

RDEFINE
CB.&<server<cluster> UACC(NONE); PERMIT &<SR_userid> ACCESS(READ)
For this example, server = server name, cluster = cluster name or cluster transition name if a cluster has not yet been created, and SR is the MVS™ user ID for the server region.

The following command provides access to controllers using dynamic Application: 

CB.& server.&<cluster>.<cell>
UACC(NONE); PERMIT &<SR_userid> ACC(READ)
For this example, server = server name, cluster = cluster name or cluster transition name if a cluster has not yet been created, cell = cell short name, and SR is the MVS user ID for the server region.

SERVER class profiles control whether a servant can call authorized routines in the associated controller.

For access to Controller using Static Application Environment, enter: 

CB.server.<cluster>
CB.<SAF profile prefix>.server.<cluster>

For access to Controller using Dynamic Application Environment, enter: 

CB.server.<cluster>.<cell>
22

Use STARTED class profiles

There are three formats of STARTED class profiles used to assign user IDs and group IDs to controllers: 

STARTED Class profiles - (MGCRE) - for control regions, daemons, and Node agents
<<CR_proc>.<CR_jobname> STDATA(USER(CR_userid) GROUP(CFG_groupid))
<demn_proc>.* STDATA(USER(demn_userid) GROUP(CFG_groupid))
 STARTED Class profiles - (ASCRE) - for servant regions and adjuncts
<SR_jobname>.<SR_jobname> STDATA(USER(SR_userid) GROUP(CFG_groupid))
 STARTED Class profiles for IJP - (MGCRE)
<MQ_ssname>.* STDATA(USER(IJP_userid) GROUP(CFG_groupid)) - These IJPs don't exist in WAS 6.1

STARTED class profiles are generated to assign user IDs to the various WebSphere Application Server for z/OS regions. Regions include:

Use APPL class profiles

An APPL class profile controls whether an authenticated user can use any applications in the cell. If a SAF profile prefix is specified, the APPL class profile name will be the SAF profile prefix name. If SAF profile prefix is not specified, the APPL class profile name will be CBS390. Refer to System Authorization Facility considerations for the operating system and application levels.

The APPL class profile only takes effect when both the APPL class is active in RACF and when the option to use the APPL profile is enabled in WebSphere. The WebSphere option can be enabled or disabled from the console by navigating to the SAF authorization options panel and setting the checkbox Use APPL profile to restrict access to the server. For more information on this setting, read about z/OS System Authorization Facility authorization.

Create multiple security configurations within a cell

We might require distinct sets of profiles within a given cell to separate logical WebSphere security domains in the enterprise, (for example, test, and production users).

We can define a SAF profile prefix during customization using the z/OS Profile Management Tool, the zpmt command, or the SAF Authorization options panel in the administration console.

Use the WAS for z/OS console to set a SAF profile prefix under Security > Global security > External authorization provider > System Authorization Facility (SAF) authorization > Configure > SAF profile prefix, which creates the following property in security.xml. 

xmi:id="Property_47" name="com.ibm.security.SAF.profilePrefix"
value="<profile_prefix>"   required="false"/>

When a SAF profile prefix identifier is set, the following profile definitions and checks are affected:

identifier is set..

This table lists the profile definitions and checks affected when SAF profile prefix identifier is set.

Class No SAF profile prefix With a SAF profile prefix
CBIND

  • CB.clustername

  • CB.BIND.clustername

  • CB.<profilePrefix>.clustername

  • CB.BIND.<profilePrefix>.clustername

EJBROLE ApplicationRoleName <profilePrefix>.ApplicationRoleName
APPL CBS390 <profilePrefix>

Generating new user IDs and Profiles for a new Server

To use unique user IDs for each new application server, define these users, groups, and profiles in the RACF database.

Through using the WebSphere z/OS Profile Management Tool or the zpmt command, we need to edit a copy of the BBOWBRAK member (or BBODBRAK depending on the type of profile) job's target .DATA partitioned data set, and change the following entries to the new users, groups, and unique New_server name, and New_cluster name profiles:

Use FACILITY and SURROGAT class profiles (Synch to OS Thread Allowed Option and the connection manager RunAs thread identity option)

The FACILITY and SURROGAT class profiles give the RACF administrator control over the use of Synch to OS Thread Allowed and the connection manager's Run-As thread identity option.

If these profiles are not defined in RACF, Sync to thread will not be allowed, and the RACF administrator will use the server ID.

The formats and use of the FACILITY and SURROGAT class profiles is as follows: 

RDEF FACILITY BBO.SYNC.<cell short name>.<cluster short name> UACC(NONE)  PE BBO.SYNC.<cell short name>.<cluster short name> CLASS(FACILITY)ID(<CR user ID>) ACC(READ or CONTROL)
RDEF SURROGAT BBO.SYNC.<Run-As user ID> UACC(NONE)  PE BBO.SYNC.<Run-As user ID> CLASS(SURROGAT) ID(<SR user ID>) ACC(READ)

The cluster short name is the server generic short name if no clustering is defined. Also, the SURROGAT class profile needs to be placed in a (RACLISTed) memory table to improve the performance of the access checks. If the <CR user ID> is given CONTROL access, then any individual user IDs that request Synch to OS Thread Allowed are allowed to synch. If the <CR user ID> is given READ access, then any individual user IDs that request Synch to OS Thread Allowed must have a SURROGAT class profile defined, and the servant region (SR) must also have READ access. For example, assume a system with cell short name of SY1, a cluster short name (the server generic short name) of BBOC001, CR user ID of CBSYMCR, SR user ID of CBSYMSR, and an application running under Run-As user ID of JavaEEID. The following commands would be used to establish Synch to OS Thread Allowed control.

Use FACILITY class profiles (Enable Trusted Applications)

The FACILITY class profile gives the RACF administrator control over the enabling of trusted applications. To enable trusted applications, define the following FACILITY class profile and give the controller region user id READ access to it. 

RDEF FACILITY BBO.TRUSTEDAPPS.<cell
short name>.<cluster short name> UACC NONE PE
BBO.TRUSTEDAPPS.<cell short name>.<cluster
short name> CLASS(FACILITY) ID(CR userid) ACC(READ)
The following generic example can be user for all servers: 
RDEFINE FACILITY BBO.TRUSTEDAPPS.mycell01.**UACC(NONE)
PERMIT BBO.TRUSTEDAPPS.mycell01.**  CLASS(FACILITY) ID(MYCBGROUP) ACCESS(READ)
SETROPTS RACLIST(FACILITY) REFRESH
The following example is for a specific server, that is, a system with a cell short name of SY1, a cluster short name (the server generic short name) or BBOC001, and a controller region userid of CBSYMCR: 
RDEF FACILITY BBO.TRUSTEDAPPS.SY1.BBOC001 UACC
NONE PE BBO.TRUSTEDAPPS.SY1.BBOC001 CLASS(FACILITY) ID(CBSYMCR) ACC(READ)

Use minimalist profiles

To minimize the number of users, groups, and profiles in the RACF data set, we can use one user ID, one group ID, and very generic profiles so they cover multiple servers in the same cell. This technique can also be used with Integral Java Message Service provider and WebSphere Application Server Network Deployment configurations.

The advantages of using minimalist profiles include having fewer:

A disadvantage is that you must more closely monitor applications because if multiple servers run with the same user IDs or groups, an application can cause problems in one server and potentially corrupt the configuration of its own server (for example, by turning security off) and other servers as well.

  • Summary of controls