This topic applies only on the z/OS operating system.

System Authorization Facility classes and profiles

When you are using Resource Access Control Facility (RACF) or System Authorization Facility (SAF) you must consider:
  1. Using roles for enterprise beans and Web applications, and servlets
  2. Using RACF class profiles
    1. Using CBIND to access servers and objects in the servers
    2. Using SERVER to access controllers using servant regions
    3. Using STARTED to associate user IDs and groups with started procedures
  3. Creating multiple security configurations within a sysplex
  4. Generating new user IDs and Profiles for a new server
  5. Using minimalist profiles

Roles for Enterprise JavaBeans and Web applications, and servlets

Roles are associated with Java 2 Platform, Enterprise Edition (J2EE) 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 security domain, if specified, becomes a prefix used by WebSphere Application Server for z/OS and RACF when checking EJBROLE profiles. This provides cell-level granularity of roles. You do not need to modify roles in the applications to achieve this.

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.

There are four profiles defined in the RACF EJBROLE class for administrative authorization. They are administrator, configurator, monitor, and operator. When using RACF for role mapping, you need to define RACF user ID or group READ access for one of these profiles, depending on the administrative authority you give to the user.

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

Using 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 your equivalent security product). You must also understand the techniques for managing the security environment.

The RACF profiles that protect the WebSphere Application Server 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
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, and STARTED class profiles.

User IDs and Group IDs

As part of the WebSphere Application Server for z/OS customization dialogs, the BBOCBRAJ job generates RACF commands that then can be run with the BBOWBRAK job. 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 you understand how they are used in the various permissions later on:
<CR_userid> <CR_groupid>, <CFG_groupid> <SR_userid> <SR_groupid>, <CFG_groupid> <demn_userid> <demn_groupid>, 
<CFG_groupid> <admin_userid> <CFG_groupid> <client_userid> <client_groupid> <ctracewtr_userid> <ctracewtr_groupid> 

Below are the various profiles used to protect the WebSphere Application Server for z/OS resources, along with the permissions and access levels.

Using 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 you are using “Security Domain Identifier”, the CBIND profiles are qualified by the “domainId” as follows:
CBIND Class profiles - access to generic servers
CB.BIND.<domainId>.<cluster> UACC(READ) 
CBIND Class profiles - access to objects in servers
CB.<domainId>.<cluster> 	UACC(READ)
CBIND profiles control access to WebSphere Application Server for z/OS servers, including Web servers running the WebSphere Application Server 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.<security domain>.<cluster> 
For access to objects within servers, enter:
CB.<cluster> CB.<security domain>.<cluster> 

Using 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 the customization dialog, both formats are predefined, and one of these is actually required at runtime. The required format is determined dynamically by the WebSphere Application Server 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.<security domain>.<server>.<cluster> 
For access to Controller using Dynamic Application Environment, enter:
CB.<server>.<cluster>.<cell>
22 

Using 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)) 
STARTED class profiles are generated to assign user IDs to the various WebSphere Application Server for z/OS regions. Regions include:

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

Creating multiple security configurations within a sysplex

You might require distinct sets of profiles within a given RACF database to separate logical WebSphere Application Server for z/OS security domains in your enterprise, (for example, test, and production users).

You can define a Security Domain Identifier during customization using the ISPF dialog panels (“Security Domain Configuration”), or in the Global Security properties panel in the administration console (security.zOS.domainName, security.zOS.domainType). On the ISPF Security Domain Configuration panel, enter:
Use Security
Domain Identifier in RACF Definitions:  <Y/N>     Security Domain Identifier....................:
 <domainId> 

Use the WebSphere Application Server for z/OS administrative console to set these variables under Security > Global Security > Custom Properties, which creates the following properties in the security.xml file in the cell’s directory:

xmi:id="Property_47" name="security.zOS.domainType"
value="cellQualified"  required="false"/> xmi:id="Property_48" name="security.zOS.domainName"
value="<domain_name>" required="false"/> 

This creates the following variables in was.env file in the server’s directory: security_zOS_domainName=<domain_name> security_zOS_domainType=1

When a security domain identifier is set, and the “Use security domain flag” is specified, the following profile definitions and checks are affected by the use of a security domain identifier:
 Class
   	domainType=None  		 domainType=cellQualified  CBIND 	    CB.clustername
       CB.domainId.clustername            CB.BIND.clustername   CB.BIND.domainId.clustername
 APPL       CBS390            	  domainId EJBROLE	  ApplicationRoleName 	
 domainId.ApplicationRoleName 

Generating new user IDs and Profiles for a new Server

If you want to use unique user IDs for each new application server, you must define these users, groups, and profiles in the RACF database.

Edit a copy of the BBOWBRAK member in the ISPF customization dialog 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:

Using minimalist profiles

To minimize the number of users, groups, and profiles in the RACF data set, you 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 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.



Related reference
Summary of controls
Concept topic    

Terms of Use | Feedback

Last updated: Aug 29, 2010 9:31:45 PM CDT
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=vela&product=was-nd-mp&topic=csecsafclasses
File name: csec_safclasses.html