WebSphere Application Server Version 6.1 Feature Pack for Web Services
             Operating Systems: z/OS

             Personalize the table of contents and search results
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
    4. Using FACILITY to establish permission to enable Synch to OS Thread Allowed
    5. Using SURROGAT to optionally establish permission to enable Synch to OS Thread Allowed
  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 six profiles defined in the RACF EJBROLE class for administrative authorization. They are administrator, configurator, monitor, operator, deployer and adminsecuritymanager. 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
  4. FACILITY: Use this class to associate user IDs and groups to the Synch to OS Thread Allowed option
  5. 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

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)) - 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:

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 > Secure administration, applications, and infrastructure > 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 FACILITY and SURROGAT class profiles (Synch to OS Thread Allowed Option)

The FACILITY and SURROGAT class profiles give the RACF administrator control over the use of Synch to OS Thread Allowed.
Attention: If these profiles are not defined in RACF, Sync to OS thread is not allowed.
The formats and use of the FACILITY and SURROGAT class profiles is as follows:
BBO.SYNC.<cell
short name>.<cluster short name> RDEF FACILITY BBO.SYNC.<cell short
name or security domain prefix>.<cluster short name> UACC NONE PE BBO.SYNC.<cell
short name or security domain prefix>.<cluster short name> CLASS(FACILITY)
ID<CR userid> ACC(READ or CONTROL)  RDEF SURROGAT BBO.SYNC.<SR userid>
UACC NONE PE BBO.SYNC.<application userid> CLASS(SURROGAT) ID(<SR userid>)
ACC(READ)
Note: 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 userid> is given CONTROL access, then any individual user ids that request Synch to OS Thread Allowed are allowed to synch. If the <CR userid> is given READ access then any individual user ids that request Synch to OS Thread Allowed must also have READ access to a SURROGAT class profile that gives the application user id explicit permission to Synch to OS Thread Allowed in the servant region (SR). For example, assume a system with cell short name of SY1, a cluster short name (the server generic short name) of BBOC001, CR userid of CBSYMCR, SR userid of CBSYMSR, and an application running under the userid of J2EEID. The following commands would be used to establish Synch to OS Thread Allowed control.
RDEF FACILITY BBO.SYNC.SY1.BBOC001 UACC NONE PE BBO.SYNC.SY1.BBOC001
CLASS(FACILITY) ID(CBSYMCR) ACC(READ) RDEF SURROGAT BBO.SYNC.J2EEID UACC
NONE PE BBO.SYNC.J2EEID CLASS(SURROGAT) ID(CBSYMSR) ACC(READ)

Using FACILITY class profiles (Enabling Trusted Applications)

The FACILITY class profile gives the RACF administrator control over the enabling of trusted applications. To enable trusted applications, you must not only perform the enablement in the administrative console, but also define the following FACILITY class profile and give the controller region user id READ access to it.
RDEF FACILITY BBO.TRUSTEDAPPS.<cell
short name or security domain prefix>.<cluster short name> UACC NONE PE
BBO.TRUSTEDAPPS.<cell short name or security domain prefix>.<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)

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: Nov 25, 2008 2:35:59 AM CST
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=/com.ibm.websphere.wsfep.multiplatform.doc/info/ae/ae/csec_safclasses.html