IOA Security

The INCONTROL family of products can be protected like any other standard facility in a data center. INCONTROL has built-in security interfaces to RACF, CA‑ACF2 and CA‑TopSecret. In most cases, you are not required to customize the security modules.

This chapter describes the procedure used to install the security interface for the IOA component.

• Security Modules: Each IOA function invokes a security module that verifies if a specified user is authorized to perform a specific function (such as, add, modify, and delete) and determines if the action is permitted or denied. Security modules are used to control access to the various protected elements.

• User Exits: User exits are invoked before the security modules to allow the user to perform any required user functions that are not related to security. However, the user exits can be customized so that both user and security functions are performed by either or both modules. It is recommended that you separate the functions because some user exits cannot perform security functions. For more information, refer to the descriptions of each security module later in this guide.

• IOASECUR Module: When any interaction with the security product is required, the common security services module, IOASECUR, is invoked. This module is invoked each time an INCONTROL product requires a security service. For example, to create the security environment, check a user’s authority, extract user information, or delete a security environment.

  The IOASECUR module determines which security product the site is using (RACF, TopSecret, or ACF2), and invokes the relevant IOA security interface module (IOARACF, IOATSS, or IOAACF2).

Defining Security Modes

Security requirements often differ from site to site. The IOA security interface provides two modes for defining security: Basic Definition mode and Extended Definition mode. The difference between the two modes is not the degree of security, but rather ease of implementation (using Basic Definition mode) compared with the level of authorization that can be granted to the user (using Extended Definition mode).

The administrator can choose to use either Basic Definition mode or Extended Definition mode to control user authorizations to each INCONTROL security module.

Basic Definition Mode

Basic Definition mode authorizes the user access to an INCONTROL protected element. A user who is granted permission to an element is authorized to perform all the actions that are valid for this element (such as add, delete, change and update). The advantage of working in this mode is that it merges several different security events into a logically grouped resource structure. This structure simplifies the administration required to implement INCONTROL security.

Extended Definition Mode

Extended Definition mode grants each user access for a specific action within each INCONTROL protected element. Therefore, a user who is granted access to an INCONTROL element can be granted or denied any action (add, delete, change and update) within that element. This definition mode requires you to define several access rules. For each action there is an associated resource structure. However, Extended Definition mode provides maximum flexibility and accuracy for granting authorizations.

Conditional Definition Mode

When working in Conditional Definition mode (Fixed vs. Conditional Definition Mode), the security module first determines the definition mode to be used. To determine the mode, the security module issues an authority check for access to the entity $$IOAEDM.qname (or $$CTxEDM.qname) in the FACILITY class. If the user is authorized for the given entity, the security module operates in Extended Definition mode. Otherwise, the security module operates in Basic Definition mode.

During the installation process, a security module can be customized to operate in a single mode (meaning, either Extended Definition mode or Basic Definition mode). For more information, see Implementing IOA Security.

Fixed vs. Conditional Definition Mode

Fixed Definition mode enables the administrator to determine the definition mode in advance. Conditional Definition mode first establishes the user’s definition mode (Basic or Extended) and then determines a user’s authority to access an entity. Conditional Definition mode provides more flexibility than Fixed Definition mode when determining a user’s authority. For example, certain users can be set to work in one mode, while others can be set to work in another mode. Using Fixed Definition mode improves the performance of the security checking process because the check for the mode is eliminated.

When Conditional Definition mode is used and a resource profile is defined to protect $$IOAEDM or $$CTxEDM entities, it is recommended that the security system not audit this resource to avoid generating failure audit records for these entities.

When Conditional Definition mode is used, one more call is made to the security product to determine the mode in which the user should operate.

Defining Security for Multiple Environments

The security definition scope is one IOA environment. If your site is running multiple IOA environments simultaneously (such as Production and Test), different security definitions can be specified for each environment. IOA installation parameter QNAME is used to distinguish between the IOA environments. For more information about this parameter, see the IOA installation chapter in the INCONTROL for z/OS Installation Guide: Installing.

Identifying Users

When planning INCONTROL security implementation, it is recommended that the security administrator identify the users or group of users for the test or production environment.

Typically, the IOA environment is intended for the following types of user categories:

• Users who install and customize INCONTROL products, and determine implementation and policy issues

• Users who create and update definitions of IOA entities, such as prerequisite conditions

• Users who use and operate INCONTROL products

• Users with special user IDs, such as long-running started tasks or specific system jobs. To determine the security related setup that these users require see Basic Definition Security Calls, and Extended Definition Security Calls.

Access to each protected element is controlled by verifying that the active user ID is authorized to perform each specific function. The specified user ID for authorization varies, depending on the environment being used. User IDs can be one of the following types:

Table 1 User IDs

When a security interface module performs a security authorization check, the user ID that is checked for the operation can be any of the user IDs described above, depending on the environment in that the operation is performed.

Implementation Overview

IOA security installation must be completed before proceeding with the security implementation of INCONTROL products.

It is recommended that the security administrator follow the implementation stages outlined below to verify that security of all INCONTROL products is successfully implemented:

• Plan the security implementation.

• Identify the types of users required for a test installation or production installation. Specify the types of security definitions required for each type of installation (for example, decide if Basic Definition mode is sufficient or if Extended Definition mode is required).

• Specify the required definitions and authorizations.

• Create the definitions required to permit the INCONTROL products installer to perform all actions.

• Specify security parameters using ICE.

• Follow the steps in ICE to specify the parameters required for the security implementation.

• Submit all security installation and customization jobs.

• Follow the steps in ICE to submit all the security installation jobs. Check all error messages produced by each job.

IOA Security Implementation

Each chapter in this guide contains a table that lists all the protected elements applicable to the INCONTROL product for that security is implemented. It is recommended that the security administrator review the table to determine the user categories and authorizations required for the protected elements in the INCONTROL products. Members (IOASRAC3 and CTxSRAC3, IOASTSS3 and CTxSTSS3, and IOASSAF3 and CTxSSAF3) in the IOA INSTWORK library contain examples that can be used as a basis for specifying the required authorizations. The job is created in the IOA INSTWORK library after selecting the "Functions Security Definitions" step in ICE.

The steps below describe the flow of the IOA security implementation process.

1. Determine the security environment for the user.

   IOA security interface modules verify that a specific user is authorized to perform a specific action. If the protected components belong to a multiuser address space (such as the ControlM monitor, the ControlD monitor, or the Online monitor) it is necessary to determine the security profile of the user within the address space. When an IOA security module is invoked under a multiuser address, the IOASECUR module determines the security profile. This service identifies the user requesting the action and builds the user’s security profile in storage. Otherwise, the user maintains the same security profile as that of the address space.

2. Determine definition mode.

   Once the security environment is determined for the user ID, the security interface determines which definition mode is required for the specified user ID or security module. The appropriate entity and CLASS are built for the user ID.

   If the chosen mode is conditional, a check for the Extended entity ($$xxxEDM) is performed and the appropriate entity and CLASS are built based on the check results. If the chosen mode is Fixed Definition mode, the appropriate entity and CLASS are built.

3. Issue security checks.

   The IOASECUR IOA security services module is invoked to perform the authority check.

4. Determine security check results.

   If the user is authorized to the specified entity, an application return code zero (authorized) is returned. If the return code from the security product indicates that the security product is not active or the specific entity is not defined to the security product, the security interface module either grants or denies the request, according to the SECTOLx security installation parameter.

   Once the authorization process is complete, the security environment is cleaned up.

   The following diagrams illustrate the detailed flow of the INCONTROL security modules, representing each of the steps described above.

   

   

• Protecting IOA Elements

• The following elements can be protected within the IOA environment:

• IOA datasets

• Login to IOA

• IOA Conditions

• IOA Manual Conditions

• ControlM Quantitative Resources

• ControlM Control Resources

• Access to the VTAM Monitor

• Operator Commands

Details of how access to each IOA element is controlled are provided below.

Dataset Protection

The following dataset types are protected under the IOA environment.

IOA Installation Libraries

INCONTROL product users must have read access for the following IOA installation libraries:

Table 2 IOA Installation Libraries

For the following IOA Installation libraries, it is recommended (but not mandatory) that IOA users be denied access and that read only access be granted to IOA administrators and maintenance personnel. Update access must be permitted only to security personnel (for example, the person installing or maintaining IOA and the IOA security administrator).

Table 3 IOA Restricted Access Libraries

IOA Operations Libraries

INCONTROL product users must have read access to these libraries. INCONTROL product administrators or selected groups of users must have update access to these libraries. The PROF Library (see below) must be a public library with update access for all IOA users, but only using programs activated from the IOA LOAD library.

Table 4 IOA Operations Libraries

IOA Files

INCONTROL product users must have update access to these datasets, but only through programs activated from the IOA LOAD library. The specific user authorization within the IOA is determined by the relevant IOA security interface module, as explained beginning on Basic Definition Security Calls.

Table 5 IOA Files

IOA Maintenance Library

It is recommended that update access to files in this library be granted only to security personnel (for example, the IOA security administrator or the person installing or maintaining IOA).

Table 6 IOA Maintenance Library

Protecting Access to Datasets Using Specific Programs

For information about how to protect access to datasets through programs and program pathing, see Limiting Access to Specific Programs.

Security Resource Classes

RACF Security

The IOA interface uses the general resource class. A different user‑defined class can be used for IOA by updating the appropriate table (for example, the Class‑Descriptor‑Table) and setting the IOACLASS parameter.

The following resource classes are used within IOA security:

Table 7 RACF Resource Classes

TopSecret Security

The IOA interface uses the general resource class. A different user‑defined class can be used for IOA by updating the appropriate TopSecret table (meaning, the RDT, Resource‑Descriptor‑Table), and setting the IOACLASS parameter.

The following resource classes are used within IOA TopSecret security:

The FACILITY class is converted by TopSecret to IBMFAC.

Table 8 TopSecret Resource Classes

ACF2/SAF Security

The IOA interface uses the general resource class. A different user‑defined class can be used for IOA by updating the appropriate ACF2 table (meaning, the CLASMAP definition in ACF2 version 6.x, or the SAFMAPS definition in ACF2 version 5.2), and setting the IOACLASS parameter.

The following resource classes are used within IOA ACF2/SAF security:

Table 9 ACF2/SAF Resource Classes

The SAF compatibility mode option must be used. The System Authorization Facility (SAF) is a basic component of MVS that enables resource managers of the operating system to request security services. The ACF2/SAF interface translates SAF security requests into ACF2 requests. SAF is invoked by issuing a RACROUTE request. For more information, see the CA-ACF2 System Programmer’s Guide.

Access to IOA Datasets

Users require access to datasets within the IOA environment. Access to IOA datasets must be granted during IOA installation. For more information on how to grant permissions to the IOA datasets, refer to the INCONTROL for z/OS Installation Guide: Installing.

Sign on to the IOA VTAM Monitor

Whenever a user attempts to sign on to the IOA VTAM monitor, the user’s ID and associated password or password phrase are verified.

The IOASE09 IOA security module verifies the user ID and password or password phrase used to sign on to the IOA VTAM monitor.

Access to the IOA Online Facility

Whenever a user attempts to access the IOA Online facility, the user’s authority is checked. This authorization check is performed for all environments in which the user attempts to access IOA, including TSO, Online monitor, CICS, ROSCOE, and so on.

The authorization check verifies that the logged on user has at least read access to a given entity associated with IOA access ($$IOAONLINE.qname), as defined in your security product.

Authorization is also checked when the IOA Online facility is accessed in batch using the IOA KeyStroke Language (KSL).

The IOASE06 IOA Security module verifies the user’s authority to use the IOA Online facility.

For details of the entity names to be defined to your security product, see Basic Definition Security Calls and Extended Definition Security Calls.

Operations on IOA Conditions and Control-M Resources

Whenever a user attempts to perform an operation on IOA conditions or Control‑M resources (for example, Add, Delete), or when the operation is performed automatically, the user’s authority is checked. The following IOA conditions and Control‑M resources are checked:

• Prerequisite conditions – common IOA facilities that control tracking of conditions that must be met before activities such as job submissions are performed.

• Control resources – common ControlM facilities that Control resource sharing between jobs.

• Quantitative resources – common ControlM facilities that control allocation of computer resources such as tapes, CPUs, and so on, to maximize system throughput.

The security interface checks every type of operation to verify that the specified user is authorized to access a specific entity, as defined in your security product. The name of the entity is derived from the name of the condition or resource being accessed, and optionally, from the type of operation requested by the user.

For example, to access a condition called SYSCOND1 in Basic Definition mode, the user must be authorized to access the entity $$IOARES.qname.SYSCOND1. To delete a resource named SYSTAPE1 in Extended Definition mode, the user must be authorized to access the entity $$DELRES.qname.SYSTAPE1.

The IOASE07 IOA security module is invoked to verify the user’s authorization to

• Add or delete a prerequisite condition to or from the IOA Conditions file.

• Add or delete a Control resource to or from the ControlM Resources file.

• Add, delete, or change a Quantitative resource to, from, or in the ControlM Resources file.

• Add a prerequisite condition to the IOA Manual Conditions file.

For more information about these elements, see Basic Definition Security Calls and Extended Definition Security Calls.

User Authorization to Issue Operator Commands

Several IOA facilities (such as IOAOPR, Control‑O rules) enable users to issue operator commands, including JES2 and JES3 commands.

The IOA security interface checks that the user is authorized to issue an operator command prior to executing the user’s operator command request.

The authorization check is done by verifying that the specified user has access to the entity $$IOACMD.qname.command, where command is derived from the command text.

For example, to authorize processing of requests to issue all operator commands, users must be authorized to access entity $$IOACMD.qname.* or $$IOACMD.qname.**

To allow a user’s request to issue the operator command ‘D J,L’, the user must be authorized to access entity $$IOACMD.qname.D.J.L

The CLASS checked is FACILITY; the entity used to check authorization is: $$IOACMD.qname.command‑text, where command text is the first 20 characters of the operator command, compressed according to the following rules:

• Multiple non-alphanumeric characters are replaced with one period.

• A dot at the end of a command is dropped.

• All nonalphanumeric characters (blanks, commas, apostrophes, and so on) are replaced withdots.

Table 10 Operator Command Checking

The IOASE12 IOA security module verifies the user’s authority to issue operator commands. This module functions in a similar manner under both Basic and Extended Definition modes.

Some IOA components internally issue JES2/operator commands and must be authorized to do so. For example, the Control-M monitor issues $G D JES2 commands when the Extended NJE facility is activated (for details, see the description of the ENHNJE parameter in the INCONTROL for z/OS Installation Guide: Customizing).

Access to User Datasets

Whenever a user attempts to perform an operation on a user dataset, the user’s authority to access the dataset and member is checked.

The IOASE32 IOA Security module verifies the user’s authority to perform an edit, view or save action on JCL members, documentation members, definition tables or calendars from the IOA Online facility.

For more details about the definitions required in your security product, see Basic Definition Security Calls and Extended Definition Security Calls.

Access to Control-D through the IOA Gateway

When a user logs on to Control‑D through the IOA Gateway from the Control‑D/Page On Demand feature, the IOASE16 security module is invoked to check the user’s user ID and password. The security module also allows the user to optionally change their own password for MVS logon procedures (for example, TSO, CICS).

Invoking Utilities

When a particular batch utility is invoked, the IOASE40 security module checks to see if the user is authorized to run the utility.

Setting Global Variables

When a user attempts to set a global variable in a directory that is not the current directory, the IOASE42 security module is invoked to check the user’s authorization to set global variables.

IOA XBM interface

A RACF call is made by XBM on the initial request to determine if a user is authorized to perform the requested function. The following RACF profile is used:

BMCXBM.<XBM_SSID>.ZIIP

If this profile is not defined, permission will be granted. More detailed information can be found in the XBM documentation.

Implementing IOA Security

This section describes the steps required to install the IOA security interface.

The IOA security interface can be installed either as part of the customized installation path, or during the Customization process after installation. Both options use the INCONTROL Installation and Customization Engine (ICE) application. If you are not familiar with the ICE interface, see the INCONTROL for z/OS Installation Guide: Installing.

During run time, the IOASECUR module determines which security product the site is using, and invokes the proper interface module (IOARACF for RACF, IOATSS for TopSecret, or IOAACF2 for ACF2/SAF) to create the security environment or clean up the security environment, and to make all necessary authorization checking. Therefore, one installation supports all three security products.

The IOA administrator must make several changes when TopSecret or ACF2 are the security products used by the site.

• To install the IOA TopSecret interface, make the following changes in the Build IOA TopSecret Interface job that you generate through ICE:
  • Specify correct library names in the lines marked with “MODIFY”.
  • For TopSecret version 14 or later, specify the name of the additional macro library as the value of the SECMACF= parameter in JCL procedure IOASMP.
• To install the IOA ACF2 interface, do the following:
1. Edit the IOASMP member in the IOA PROCLIB library.

2. Add the following line, ensuring that the DSN parameters points to the correct library:
   //ACFMOD DD DISP=SHR,DSN=ACF2.LOAD.LIBRARY

3. Change the library name of the SECMACF parameter to point to the ACF2 macro library.

4. Save the member.

To install the IOA security interface

1. Enter the main ICE screen.

2. Select Customization.

3. Enter IOA in the Product field.

4. Select Security Customization.

5. Perform all major and minor steps required to install the security product.

Step 1. Implement IOA Security

Use the following steps that correspond to the installation steps in ICE, to implement IOA security.

Step 1.1 Grant Access Permissions

Authorizations to access IOA datasets are optionally defined during IOA installation. It is recommended that this step be completed before proceeding with security implementation. For information about how to grant users access to IOA datasets, see the IOA installation chapter in the INCONTROL for z/OS Installation Guide: Installing.

Step 1.2 Customize Security Parameters

The following table describes the required parameters and their values:

Table 11 Customized Security Parameters

Step 1.3 Save Security Parameters into Product

This step saves all the security parameters specified for IOA.

When this step is completed, the Status column is automatically updated to COMPLETE.

Step 1.4 Select Security Product Interface

The IOA installation supports RACF, TopSecret, and ACF2. The IOA security interface automatically determines which security product is being used at runtime. More than one security product can be selected.

Specify the security products you want to support, and follow the instructions in this step.

Step 1.5 Build IOA RACF Interface

The IOASRACF job in the IOA INSTWORK library creates the IOA security interface module for RACF.

Submit the job. All steps of this job must end with a condition code of 4 or less.

Step 1.6 Build IOA TopSecret Interface

The IOASTSS job in the IOA INSTWORK library creates the IOA security interface module for TopSecret.

Submit the job. All steps of this job must end with a condition code of 4 or less.

Check all lines that are marked with "MODIFY" and ensure that the proper dataset names are set.

Step 1.7 Build IOA ACF2 Interface

The IOASSAF job in the IOA INSTWORK library creates the IOA security interface module for ACF2.

Submit the job. All steps of this job must end with a condition code of 4 or less.

Check all lines that are marked with "MODIFY" and ensure that the proper dataset names are set.

Step 1.8 Activating IOA and INCONTROL Product Security

To activate the IOA security or any INCONTROL product security, the security administrator must define the following entities in the relevant security product:

• For IOA, define entity $$SECIOA.qname

• For ControlM, define entity $$SECCTM.qname

• For ControlD, define entity $$SECCTD.qname

• For ControlO, define entity $$SECCTO.qname

• For ControlM/Analyzer, define entity $$SECCTB.qname

• For ControlM/Tape, define entity $$SECCTT.qname

where qname is defined during the IOA installation process.

BMC recommends that you define the entities as fully qualified in order to distinguish between different environments, and define the entities with universal READ access.

The class which these entities must be defined are as follows:

• RACF — The class is FACILITY

• TopSecret — The class is IBMFAC

• ACF2 — The resource type is CMF

Step 2. Link IOA Security Modules (Optional)

• Step 2.1 Link Security Modules to IOA COMPLETE Online Interface Modules (Optional)

  The IOASCPL job in the IOA INSTWORK library is optional. This job is used only if COMPLETE is installed.

  Submit this job to set SMP/E to link the security modules into the IOA COMPLETE online interface modules.

  This job must end with a condition code of 4 or less.

Check all lines that are marked with "MODIFY" and make sure that the proper dataset names are specified.

• Step 2.2 Link Security Modules into IOA IDMS Online Interface Modules (Optional)

  The IOASIDM job in the IOA INSTWORK library is optional. This job is used only if IDMS is installed.

  Submit this job to set SMP/E to link the security modules to the IOA IDMS online interface modules.

  This job must end with a condition code of 4 or less.

Check all lines that are marked with "MODIFY" and make sure that the proper dataset names are specified.

• Step 2.3 Link Security Modules into IOA IMS Online Interface Modules (Optional)

  The IOASIMS job in the IOA INSTWORK library is optional. This job is used only if IMS is installed.

  Submit this job to set SMP/E to link the security modules to the IOA IMS online interface modules.

  This job must end with a condition code of 4 or less.

Check all lines that are marked with "MODIFY" and make sure that the proper dataset names are specified.

Step 3. RACF Security Definition Samples (Optional)

A RACF call is made by XBM on the initial request to determine if a user is authorized to perform the requested function. The following RACF profile is used:

BMCXBM.<XBM_SSID>.ZIIP

If this profile is not defined, permission will be granted. More detailed information can be found in the XBM documentation.

Step 3.1 IOA Security Definitions (Optional)

IOA security definition samples are found in the IOASRAC2 member of the IOA INSTWORK library. This member is created in the IOA INSTWORK library after selecting this step.

1. Associate users with extended definition mode.

   1. When using Conditional Definition mode, define the entity $$IOAEDM.qname using the following command:

      Copy

      RDEFINE FACILITY $$IOAEDM.qname UACC(NONE)

      Force USERA to work in the Extended Definition mode by using the following command:

      PERMIT $$IOAEDM.qname ID(USERA) CLASS(FACILITY) ACCESS(READ)

      Users who have read authority to this entity will work in the Extended Definition mode. Users who are not authorized to access this entity work in the Basic Definition mode.

   2. Submit the job for execution.

2. Verify that the SURROGAT class is active.

   1. Use the following command to list the active classes:

      Copy

      SETROPTS LIST

   2. To activate the SURROGAT class, use the following command:

      Copy

      SETROPTS CLASSACT(SURROGAT)

Step 3.2 Function Security Definitions (Optional)

The IOASRAC3 job in the IOA INSTWORK library is optional. It contains some definition samples for various entities. Customize this job according to your requirements and submit the job.

Define entities and user authorizations.

For information about defining IOA entities and user authorizations, see Basic Definition Security Calls, and Extended Definition Security Calls.

Examples

The IOASRAC4 job in the IOA INSTWORK library contains a sample of the definitions required to define Program Pathing access authorizations to IOA datasets. Review the definitions and modify them according to the requirements of your site.

• To control access to the IOA Online facility, specify the following command:

  Copy

  RDEFINE FACILITY $$IOAONLINE.qname

  where qname is used to assign different authorizations to different IOA environments (such as Test and Production). This parameter is specified during IOA installation.

• To define and authorize all conditions beginning with SYS, use the following command:

  Copy

  RDEFINE FACILITY $$IOARES.qname.SYS*
  PERMIT $$IOARES.qname.SYS* CLASS(FACILITY) ID(USERA) ACCESS(READ)

• To authorize USERA access to a given IOA entity, use the following command:

  Copy

  PERMIT $$IOAnnn.qname CLASS(FACILITY) ID(USERA) ACCESS(READ)

  All entity names for each IOA protected element appear in Basic Definition Security Calls for Basic Definition mode and Extended Definition Security Calls, for Extended Definition mode.

Step 3.3 Control Program Access to IOA Datasets (Optional)

The IOASRAC4 job in the IOA INSTWORK library contains a sample of the definitions required to define Program Pathing access authorizations to IOA datasets. Review the definitions and modify them according to the requirements of your site.

Step 4. TopSecret Security Definition Samples (Optional)

Step 4.1 IOA Security Definitions (Optional)

IOA security definition samples are found in the IOASTSS2 member of the IOA INSTWORK library. The IOASTSS2 member is created in the IOA INSTWORK library after selecting this step.

1. Define IOA monitors in the TopSecret Facility Matrix

   IOASTSS2 contains the necessary command to dynamically define IOA in TopSecret Facility Matrix.

   1. Modify USER1 in the facility definition command to a free entry in the Facility Matrix, as follows:

      Copy

      TSS MODIFY FAC(USER1=NAME=IOA)

      This command defines IOA in the Facility Matrix until the next IPL.

   2. Update the TopSecret parameter member, usually called TSSPARM0, to permanently define the facility.

   3. Copy the IOA facility definition from the IOASTSS5 member in the IOA BASE INSTALL library to the TSSPARM0 member.

   4. Update the Facility Matrix entry name to the same name that is specified in the TSS MODIFY command.

2. Define IOA ACID to TopSecret

   Change the DEPT parameter value from security administrator, department to the appropriate ACID:

   Copy

   TSS CRE(IOA) NAME (...) DEPT(sec-administrator-dept)

3. Define IOA procedures (started tasks) to TopSecret

   Change the ACID definition in the following commands to the appropriate ACID:

   Copy

   TSS ADD(STC) PROC(IOAOMON1) ACID(IOA)
   TSS ADD(STC) PROC(IOAVMON) ACID(IOA)

4. Connect the appropriate profile to the IOA ACID in the following command:

   Copy

   TSS ADD(IOA) PROF(profile-name)

   IOAOMON must be authorized to any datasets that are accessed by online users.

5. Connect usera to the IOA ACID in the following command:

   Copy

   TSS ADD(usera) FAC(IOA)

6. Define IOA entities and user authorizations to TopSecret

   For information about how to define IOA entities and user authorizations to TopSecret, see Basic Definition Security Calls, and Extended Definition Security Calls.

   Modify the following command to establish resource ownership in TopSecret to the appropriate owner:

   Copy

   TSS ADD(sec-administrator-dept) IBMFAC($$IOA)

   For samples of user authorizations, review member IOASTSS3 in the IOA INSTWORK library.

   All entity names for each IOA protected element appear in Basic Definition Security Calls, for Basic Definition mode and Extended Definition Security Calls, for Extended Definition mode.

7. Associate users with Extended Definition modes

   Customize the following TopSecret command to establish Extended Definition mode for the IOA installer.

   Copy

   TSS PERMIT (USERA) IBMFAC($$IOAEDM.qname) ACC(READ)

   Change USERA to the UID of IOA installer.

   When an IOA security module is customized to CONDitional mode without access to this entity, the user works in Basic Definition mode. With access, the user works in Extended Definition mode.

   Do not define the $$IOAEDM entity to operate in warning mode since this causes all users to operate in Extended Definition mode.

8. Authorize the IOA installer to use IOA facilities.

   1. Customize the following command to authorize USERA access to the Online monitor:

      Copy

      TSS ADD(USERA) FACILITY(IOA)

   2. Change USERA to the user ID of the IOA installer.

   3. Customize the following command to authorize the IOA installer to use IOA facilities:

      Copy

      TSS PERMIT(USERA) IBMFAC($$IOA) ACC(READ)

   4. Submit the job.

      This job must be run under the ACID of the general security administrator (SCA) who has authorization to enter TopSecret commands.

      All job steps must end with a condition code of zero.

Step 4.2 Function Security Definitions (Optional)

The IOASTSS3 job in the IOA INSTWORK library is optional. It contains some definition samples for various entities. Customize this job according to your requirements and submit this job.

Step 4.3 Control Program Access to IOA Datasets (Optional)

The IOASTSS4 job in the IOA INSTWORK library contains a sample of the definitions required to define Program Pathing access authorizations to IOA datasets. Review the definitions and modify them according to the requirements of your site.

Step 4.4 Define IOA to TopSecret Facility Matrix (Optional)

The IOASTSS5 member in the IOA INSTWORK library contains the necessary definitions to define IOA in TopSecret Facility Matrix.

Modify USER1 in the facility definition command to a free entry in the Facility Matrix, by copying the IOA facility definition from this member (IOASTSS5) member in the IOA BASE INSTALL library to the TSSPARM0 member.

Step 5. ACF2 Security Definition Samples (Optional)

Step 5.1 IOA Security Definitions (Optional)

IOA security definition samples are found in the IOASSAF2 member of the IOA INSTWORK library. The IOASSAF2 member is created in the IOA INSTWORK library after selecting this step.

Review this member and make all required changes according to your site.

1. Define IOA to CA-ACF2/SAF interface.

   The IOASSAF2 member contains ACF2 commands that translate the SAF class FACILITY to the ACF2 resource type CMF.

   If the SAF class FACILITY is already in use, check if this class is translated to another ACF resource type. Specify the following command:

   Copy

   SET CONTROL(GSO) SYSID(****)
   SHOW CLASMAP

   For versions prior to ACF2 version 6.0, specify the following command:

   Copy

   SET CONTROL(GSO) SYSID(****)
   LIST SAFMAPS

   This command determines the resource type to which the class FACILITY is translated. If the resource type is not CMF, change all occurrences of resource type "CMF" in this member to the resource type in use.

2. Associating users with Extended Definition mode

   Add the following ACF2 commands to define the $$IOAEDM entity to ACF2 and authorize users to this entity.

   Copy

   SET RESOURCE(CMF)
   COMP
   $KEY($$IOAEDM.qname)
    UID(USERA) ALLOW

   If the user does not have access to this entity, the user is set to work in Basic Definition mode. Otherwise, the user is set to work in Extended Definition mode.

3. Submit the job.

   Verify that all job steps end with a condition code of 0.

   This job must be run under a user of an ACF2 administrator who is authorized to enter these ACF2 commands.

4. Refresh ACF2 definitions.

   Issue the following MVS commands to refresh the definitions of the ACF2:

   Copy

   F ACF2,REFRESH(SAFDEF)
   F ACF2,REFRESH(CLASMAP)

   For versions prior to ACF2 version 6.0, run the commands:

   Copy

   F ACF2,REFRESH (OPTS)
   F ACF2,REFRESH (SAFMAPS)

5. Rebuild the resource type CMF rules.

   Issue the following MVS command:

   Copy

   F ACF2,REBUILD(CMF)

   Add the ACF2 commands to the GSO member in the ACF2 parameter library. These commands are specified in the IOASSAF2 member.

   This job must end with a condition code of 4 or less.

Step 5.2 Function Security Definitions (Optional)

Job IOASSAF3 in the IOA INSTWORK library is optional. It contains some definition samples for various entities. Customize this job according to your use and submit this job.

1. Define entities and user authorizations to ACF2.

   For information about how to define IOA entities and user authorizations to ACF2, see Basic Definition Security Calls and Extended Definition Security Calls.

   To permit USERA to use the IOA Online facility, specify the following command:

   Copy

   SET RESOURCE(CMF)
   COMP
   $KEY($$IOAEDM.qname)
    UID(USERA) ALLOW

   where qname is the name used to assign different authorizations to different IOA environments (such as Test and Production). This parameter is specified during IOA installation.

   To define and authorize all conditions beginning with SYS, use the following command:

   Copy

   SET RESOURCE(CMF)
   COMP
   $KEY($$IOARES.qname.SYS************************)
    UID(USERA) ALLOW

   To authorize USERA (the user ID of the IOA installer) access to a given IOA entity, use the following command:

   Copy

   SET RESOURCE(CMF)
   COMP
   $KEY($$IOAnnn.qname)
    UID(USERA) ALLOW

   All entity names for each IOA protected element appear in Basic Definition Security Calls and Extended Definition Security Calls.

2. Submit the job.

   Verify that all job steps end with a condition code of 0.

   This job must be run under a user of an ACF2 administrator who is authorized to enter these ACF2 commands.

Step 5.3 Control Program Access to IOA Datasets (Optional)

The IOASSAF4 job in the IOA INSTWORK library contains a sample of the definitions required to define Program Pathing access authorizations to IOA datasets. Review the definitions and modify them according to the requirements of your site.

Step 5.4 Define IOA to CA-ACF2/SAF Interface (Optional)

The IOASSAF5 job in the IOA INSTWORK library contains a sample of the definitions to ACF2. Review this job and make all required modifications according to the requirements of your site, and submit the job.

1. Rebuild the resource type CMF rules.

   1. Issue the following MVS command:

      Copy

      F ACF2,REBUILD(CMF)

   2. Add the ACF2 commands to the GSO member in the ACF2 parameter library. These commands are specified in member IOASSAF5. This job must end with a condition code of 4 or less.

IOA Security Interface Modules

This section provides details on each IOA security interface module and user exit.

Basic Definition Security Calls

Table 12 IOA Basic Definition Security Calls

Extended Definition Security Calls

Table 13 IOA Extended Definition Security Calls

Module IOASE06

The IOASE06 module is the security module of IOA Exit IOAX006. This module checks a user’s authority to enter the IOA Online environment. Optionally, an IOA Entry Panel is displayed requiring the user to specify user ID and password or password phrase.

The module does not display the IOA Entry Panel as a default because it is assumed that the user has already passed through a logon screen when entering the current online environment (for example, session manager, TSO entry screen, CICS sign on screen).

When the module is invoked under the IOA Online monitor, it creates the User Security Profile (ACEE). The Online monitor is a multiuser address space, and different users can have different access authorizations. Under a single user address space such as a TSO user, or a batch job, the security profile initialization has already been performed by the operating system.

Use User Exit IOAX006 to perform user functions, and the IOASE06 module to perform security functions.

User Exit IOAX006 does not return to the IOA entry panel. The IOA entry panel can only be displayed by the IOASE06 security module.

The IOASE06 security module and user Exit IOAX006 are also invoked when using the IOA KeyStroke Reporting Language (KSL), that performs IOA Online functions in batch. Therefore, the same security functions are performed under all IOA environments.

Module IOASE07

The IOASE07 module is the security module of IOA Exit IOAX007. This module verifies the user’s authorization to add, delete, or change prerequisite conditions, Control resources and Quantitative resources.

The CLASS checked is FACILITY; the entity used to check authorization depends on whether Basic or Extended definition modes are used:

CMEM Default User ID

This module checks the user's authorization to perform a CMEM DO COND statement when runtime security is not active (the rule’s RUNTSEC parameter is set to NONE). If the rule’s OWNER parameter is set to CTMCTLM, user ID CTMCTLM is checked. Otherwise, user ID CTOCTLO is checked.

Basic Definition Mode

The entity used to check authorization is $$IOARES.qname.name , where name is the resource name or the condition name.

Extended Definition Mode

The entity built for verification depends on what screen is being used:

Screen 4 – Conditions/Resources Screen

For prerequisite conditions, use the actions listed in the following table:

Table 14 Prerequisite Condition Actions

For quantitative resources, use the actions listed in the following table:

Table 15 Quantitative Resource Actions

For control resources, use the actions listed in the following table:

Table 16 Control Resource Actions

Screen 7 – Manual Conditions Screen

Table 17 Manual Condition Actions

Module IOASE09

The IOASE09 module is the security module of IOA Exit IOAX009. This module checks the user’s authority to enter the IOA Online environment under CICS, IMS/DC, VTAM, IDMS/DC, COM‑PLETE, ROSCOE and TSO cross‑memory options. It is not invoked under TSO (native or ISPF), or native ROSCOE.

Optionally, a site can choose to display an IOA entry panel, requiring the user to specify user ID and password or password phrase.

The IOASE09 module is invoked under the user environment (for example, CICS). When a check is successfully passed, the IOA Online monitor is invoked. The IOASE06 module is also invoked using the user ID passed from the user environment; it performs an additional security check.

The IOASE09 module displays the IOA entry panel as a default only by IOAVMON. Otherwise, it is assumed that the user has already passed through an entry or password screen when entering the current online environment. However, the IOA entry panel is displayed under IOAVMON. The user ID and password or password phrase is verified.

Use Exit IOAX009 to perform any required user functions, while IOASE09 should be used for security functions. Note that user Exit IOAX009 cannot display the IOA entry panel. This can only be done through the IOASE09 security module.

Module IOASE12

The IOASE12 module is the security module of IOA Exit IOAX012. This module verifies that a user is authorized to issue an operator command from within the IOA environment as a result of a user action or request. The IOA utilities IOAOPR, CTMOPR, CTDOPR allow users to issue operator commands, including JES2 and JES3 commands. These utilities are also activated under CTMTDAY, CTDNDAY, the Control‑O monitor and whenever the user activates the program CTM34F.

For additional information, see User Authorization to Issue Operator Commands.

Module IOASE16

The IOASE16 module is the security module of IOA Exit IOAX016. This module is called when a logon request is made by Control‑D/Page On Demand using the IOA Gateway (IOAGATE). This module determines and builds the user’s identity for all subsequent actions. The ACEE control block is built and its address is saved in the OCT (Online Control Table). All authorization checks are performed using the user’s ACEE control block. If the ACEE control block is not built, the security interface will probably not perform the authorization checks correctly. To build the ACEE control block, the user must be defined to your security product and must have READ access to entity $$IOAAS.qname.

Module IOASE32

The IOASE32 module is the security module of IOA user Exit IOAX032. This module verifies that the user is authorized to Edit or View JCL members, documentation members, tables or calendars from the CTMAS workstation.

Basic Definition Mode

The CLASS checked is DATASET and the entity built is the dataset name of the library.

The access level used to check this authorization depends on user request:

Table 18 Basic Definition Request Authorization

Extended Definition Mode

Two checks are performed:

1. Dataset access

   The CLASS checked is DATASET. The entity used to check authorization is: the dataset name of the library. The access level used to check this authorization depends on the user request:

   Table 19 Extended Definition Request Authorization

   Request	Authorization
   EDIT request	read
   SAVE request	update
   VIEW request	read
   DIR request	read
   DEL request	update

2. Operations

   Under IOA, the CLASS checked is FACILITY. The entity used to check authorization depends on the user request:

   Table 20 Operation Access

   Request	Authorization
   DIR	$$IOADIR.qname
   EDIT	$$IOAEDT.qname.member
   VIEW	$$IOAVIW.qname.member
   SAVE	$$IOASAV.qname.member
   DEL	$$IOADEL.qname.member

Module IOASE40

The IOASE40 module verifies that the user is authorized to invoke batch utilities. This module is activated when the following utilities are invoked:

• IOADDC

• IOAVERFY

• CTTPTI

The CLASS checked is FACILITY and the entity used to check authorization is

$$IOAUTL.qname.utility-name

where utility-name is the name of the utility being invoked.

Module IOASE42

The IOASE42 module verifies that the user is authorized to create and/or update the IOA Global variable database. This module is always in the EXTEND mode.

IOASE042 protects the IOA Global variable database in ADMIN and non‑ADMIN mode.

The CLASS checked is FACILITY and the entity used to check authorization depends on the user request, as described in the following tables (where database is the database name):

Table 21 Operation Access non-IOAVAR database

Table 22 Operation Access IOAVAR database

(where application is the application name in the variable name)

Installing Control-M Application Server Security

The Control‑M Application Server (CTMAS) security interface uses the security mechanisms provided for IOA and Control‑M. For each Control‑M/Enterprise Manager user operation (for example, Hold, Rerun), the workstation gateway transfers the requesting Control‑M/Enterprise Manager user ID to the application server. The application server checks the authorization of this user using the IOA and Control‑M security modules. If the user is not authorized to perform this operation, the operation is rejected and the workstation issues an error message.

User IDs are always defined in uppercase letters on the mainframe. User IDs are usually defined in lowercase under Unix. Therefore, the application server automatically converts the workstation user IDs to uppercase for compatibility with the mainframe definitions.

Implementing CTMAS Security

Before implementing CTMAS security, the security administrator should read this section, and be familiar with ICE.

Protecting CTMAS Elements

CTMAS security uses the standard IOA and Control‑M security interfaces to protect the following elements:

• IOA conditions (the IOASE07 IOA security module)

• Jobs displayed in the Active Environment screen (the CTMSE08 ControlM security module)

• JCL members, documentation members, job orders in the Active Jobs file, tables, and calendars (the IOASE32 IOA security module)

Controlling Operations on IOA Conditions and Control-M Resources

The IOASE07 IOA security module is invoked to verify the user’s authorization to

• Add or delete a prerequisite condition to or from the IOA Conditions file.

• Add or delete a Control resource to or from the ControlM Resources file.

• Add, delete, or change a Quantitative resource to, from, or in the ControlM Resources file.

• Add or erase a prerequisite condition from the IOA Manual Conditions file.

For more information, see Module IOASE07.

Controlling Access to Edit, Save, or View JCL, Documentation, Table and Calendar Members

Although Control‑M/Enterprise Manager users do not operate directly in the mainframe environment, they can issue a request to edit, save, or view user datasets, JCL members, documentation members, tables, calendars, and so on through the Control‑M Application Server (CTMAS). The IOASE32 IOA security module is invoked to verify the user’s authority to perform such operations. For more information, see Module IOASE32.

Controlling Access to Jobs in the Active Jobs File

User actions performed in the Control‑M/Enterprise Manager application are similar to the same user actions performed under Screen 3 in Control‑M. Therefore, when a Control‑M/Enterprise Manager user issues inquiries about a job within the Active Jobs file, or attempts to change a job’s status through Screen 3, the CTMSE08 security module is invoked to verify that the user is authorized to perform the attempted action. For more information, see Module CTMSE08, and Control-M Security.

Access to the M2G file

The M2G dataset is shared by CTMAS, Control-M and (optionally) other INCONTROL products that can issue SHOUT messages to Control-M/Enterprise Manager (such as Control-O and Control-M/Analyzer). Therefore, the M2G file requires update authority for these products.

CTMAS Basic Definition Security Calls

Table 23 CTMAS Basic Definition Security Calls

CTMAS Extended Definition Security Calls

Table 24 CTMAS Extended Definition Security Calls

Step 6. Control-M Application Server — RACF

Step 6.1 Grant Access Permission

Collect the required data in order to define the INCONTROL entities and user authorizations to the security product.

You can use this data in the sample jobs provided in the subsequent steps "Control‑M Application Server Security Definitions (Sample)" and "Functions Security Definitions (Sample)".

Step 6.2 Security Definitions (Sample)

To define CTMAS security, edit the ECSSRAC2 member in the IOA INSTWORK library to perform the following actions.

1. Define entities and user authorizations to RACF.

   For details about entities and user authorizations, see the Protected Elements tables in CTMAS Basic Definition Security Calls, and in CTMAS Extended Definition Security Calls.

2. To authorize USERA (the user ID of the ControlM/Enterprise Manager installer) access to a given CTMAS entity, use the following command:

   Copy

   PERMIT $$ECSnnn.qname CLASS(FACILITY) ID(USERA) ACCESS(READ)

   where ECSnnn is the name of the CTMAS entity to be accessed.

3. Change USERA to the user ID of the CTMAS installer.

   All entity names for each CTMAS protected element are described in CTMAS Basic Definition Security Calls, for Basic Definition mode, and in CTMAS Extended Definition Security Calls, for Extended Definition mode.

4. Submit the job for execution.

   This job must be run under a user of a RACF administrator who has authorization to enter these RACF commands.

5. Scan the output of the job for information and error messages produced by RACF.

Step 6.3 Functions Security Definitions (Sample)

Select this step to edit the ECSSRAC3 member in the IOA INSTWORK library. This member contains a sample of the various definitions required to define access authorizations to various CTMAS entities. Review the definitions and modify to meet your site's requirements.

Step 7. Control-M Application Server - TopSecret

Step 7.1 Grant Access Permission

Collect the required data in order to define the INCONTROL entities and user authorizations to the security product.

You can use this data in the sample jobs provided in the subsequent steps "Control‑M Application Server Security Definitions (Sample)" and "Functions Security Definitions (Sample)".

Select the appropriate step to create the sample job by ICE. After the job is created, you can enter and save your definitions in the INSTWORK library.

Step 7.2 Security Definitions (Sample)

To define CTMAS security, edit the ECSSTSS2 member in the IOA INSTWORK library and customize it as follows.

CTMAS security uses the IOASE07 and IOASE32 IOA security modules, as well as the CTMSE08 Control‑M security module, when IOA and Control‑M security interfaces are installed. Therefore, to complete CTMAS security, only the required definitions are necessary.

1. Define CTMAS ACID to TopSecret.

   1. Change the value of parameter DEPT from secadministratordept to the appropriate ACID:

      Copy

      TSS CRE (CTMAS) NAME (...) DEPT(secadministratordept)

   2. Define the CTMAS started task to TopSecret.

      Change the ACID definition in the following command to the appropriate ACID:

      Copy

      TSS ADD(STC) PROC(CTMAS) ACID(CTMAS)

   3. Allow CTMAS ACID to access IOA datasets.

      Authorizations to access IOA datasets are optionally defined during the IOA installation process. This step must be completed before proceeding with security implementation. For information about how to grant users access to IOA datasets, see the IOA Installation chapter of the INCONTROL for z/OS Installation Guide: Installing.

   4. Connect the appropriate profile to the CTMAS ACID in the following command:

      Copy

      TSS ADD (CTMAS) PROF (profilename)

2. Give CTMAS READ access authority to any datasets that are accessed by workstation users.

   1. Define IOA entities and user authorizations to TopSecret

      For information about how to define ControlM/Enterprise Manager entities and user authorizations to TopSecret, see Basic Definition Security Calls, and Extended Definition Security Calls.

   2. Modify the following command to establish ownership of the resources in TopSecret to the appropriate owner:

      Copy

      TSS ADD(secadministratordept) IBMFAC($$ECS)

   For samples of user authorizations, see member ECSSTSS3 in the IOA INSTWORK library.

   All entity names for each CTMAS protected element are described in CTMAS Basic Definition Security Calls, for Basic Definition mode and in CTMAS Extended Definition Security Calls, for Extended Definition mode.

   1. Authorize the CTMAS installer to use CTMAS facilities.

      Customize the following command to authorize USERA access to the Online monitor:

      Copy

      TSS ADD(USERA) FACILITY(CTW)

   2. Modify USERA to the user ID of the CTMAS installer.

      Customize the following command to authorize the CTMAS installer to use CTMAS facilities:

      Copy

      TSS PERMIT(USERA) IBMFAC($$ECS) ACC(READ)

3. Submit the job

   Submit the job and verify that all steps complete with a condition code of zero. Run this job under the ACID of the general security administrator (SCA) who has authorization to enter these TopSecret commands.

4. Verify that all job steps end with a condition code of 4 or less.

Step 7.3 Functions Security Definitions (Sample)

Select this step to edit the ECSSTSS3 member in the IOA INSTWORK library. This member contains a sample of the various definitions required to define access authorizations to various CTMAS entities. Review the definitions and modify to meet your site's requirements.

Step 8. Control-M Application Server - ACF2

Step 8.1 Grant Access Permission

Collect the required data in order to define the INCONTROL entities and user authorizations to the security product.

You can use this data in the sample jobs provided in the subsequent steps "Control‑M Application Server Security Definitions (Sample)" and "Functions Security Definitions (Sample)".

Select the appropriate step to create the sample job by ICE. After the job is created, you can enter and save your definitions in the INSTWORK library.

Step 8.2 Security Definitions (Sample)

Define CTMAS security in the following steps.

CTMAS security uses the IOASE07 and IOASE32 IOA security modules, as well as the CTMSE08 Control‑M security module, when IOA and Control‑M security interfaces are installed. Therefore, to complete CTMAS security, only the required definitions are necessary.

1. Define a CTMAS started task

   Define a Logon ID for the CTMAS started task with a multi-user address space (MUSSAS) parameter.

2. Define entities and user authorizations to ACF2/SAF

   1. Edit member ECSSSAF2 in the IOA INSTWORK library. For details about entities and user authorizations, see CTMAS Basic Definition Security Calls, and CTMAS Extended Definition Security Calls.

   2. Authorize USERA (the user ID of the ControlM installer) access to a given CTMAS entity, use the following command:

      Copy

      SET RESOURCE(CMF)
      COMP
      $KEY($$ECSnnn.qname)
       UID(USERA) ALLOW

      where ECSnnn is the name of the CTMAS entity to be accessed.

   3. Change USERA to the UID string of the CTMAS installer.

      All entity names for each CTMAS protected element are described in CTMAS Basic Definition Security Calls, for Basic Definition mode, and in CTMAS Extended Definition Security Calls, for Extended Definition mode.

   For samples of user authorizations, review member ECSSSAF3 in the IOA INSTWORK library.

3. Submit the job

   Verify that all job steps complete with a condition code of zero.

   This job must be run under a user of an ACF2 administrator who is authorized to enter these ACF2 commands.

   Scan the output of the job for information and error messages produced by ACF2. All job steps must end with a condition code of 4 or less.

Step 8.3 Functions Security Definitions (Sample)

Select this step to edit the ECSSSAF3 member in the IOA INSTWORK library. This member contains a sample of the various definitions required to define access authorizations to various CTMAS entities. Review the definitions and modify to meet your site's requirements.

Security Interface Modules

This section describes the IOASE07, IOASE32, and CTMSE08 security modules in detail.

Module IOASE07

The IOASE07 module is the security module of IOA Exit IOAX007. This module verifies the user’s authorization to add, delete, or change prerequisite conditions, Control resources and Quantitative resources.

The CLASS checked is FACILITY; the entity used to check authorization depends on whether Basic or Extended definition modes are used:

Basic Definition Mode

The entity used to check authorization is $$IOARES.qname.name, where name is the resource name or the condition name.

Extended Definition Mode

The entity built for verification depends on what screen is being used.

Table 25 Screen 4 – IOA Conditions/Resources Screen

Table 26 Screen 7 – IOA Manual Conditions Screen

Module IOASE32

The IOASE32 module is the security module of IOA user Exit IOAX032. This module verifies that the user is authorized to Edit or View JCL members, documentation members, tables or calendars from the CTMAS workstation.

Basic Definition Mode

The CLASS checked is DATASET; the entity built is the dataset name of the library.

The access level used to check this authorization depends on user request:

• SAVE request: update

• VIEW request: read

• EDIT request: read

Extended Definition Mode

Two checks are performed:

1. Dataset access

   The CLASS checked is DATASET. The entity used to check authorization is: the dataset name of the library. Theaccess level used to check this authorization depends on the user request:

   SAVE request: update

   VIEW request: read

   EDIT request: read

2. Operations

   Under IOA, the CLASS checked is FACILITY. The entity used to check authorization depends on the user request:

   Table 27 Request Authorization Entity

   Request	Entity
   EDITJCL	$$ECSEDJ.qname.member
   SAVEJCL	$$ECSSVJ.qname.member
   VIEWJCL	$$ECSVWJ.qname.member
   EDITDOC	$$ECSEDD.qname.member
   SAVEDOC	$$ECSSVD.qname.member
   VIEWDOC	$$ECSVWD.qname.member
   EDITDEF	$$ECSEDF.qname.member
   SAVEDEF	$$ECSSVF.qname.member
   VIEF	$$ECSVWF.qname.member
   DELETTB	$$ECSTTB.qname.table
   DELETCL	$$ECSTCL.qname.cal

Module CTMSE08

The CTMSE08 Control‑M security module verifies that the user is authorized to perform actions (for example, hold, delete, rerun) on jobs displayed in the Active Environment screen (Screen 3).

Basic Definition Mode

Initial Access to Screen 3

IOASECUR is called to issue a security check for authorization. The CLASS checked is FACILITY; the entity checked is $$CTMPNL3.qname.

Subsequent Operations in Screen 3

For all actions (for example, hold, delete, rerun) that are performed on this screen, the IOASECUR module is called to issue a security check for authorization. The CLASS and entity checked is:

For RACF:

SURROGAT
 owner.SUBMIT

For TopSecret:

ACIDCHK
 owner

For ACF2/SAF:

FACILITY
 $SUBMIT.owner

The check verifies that the current user who has the authority to submit jobs with a USER parameter is equal to that of the specific job being accessed. A user who is authorized to submit a job on behalf of others is also authorized to perform the specific action (for example, hold, delete, rerun) on jobs belonging to other users.

Extended Definition Mode

Initial access to Screen 3

IOASECUR is called to issue a security check for authorization. The CLASS checked is FACILITY; the entity checked is $$CTMPNL3.qname.

Subsequent Operations in Screen 3

The actions (for example, hold, delete, rerun, and so on) are separated into different categories of access authority to the Active Environment screen (Screen 3).

The CLASS checked is FACILITY. The entity checked is $$JOBxrrr.qname.owner

where

• owner is the owner specified in the Job Scheduling Definition screen (Screen 2)
• x is the onedigit action identifier
• rrr is the threecharacter identifier for each action, described in the following table:

Table 28 Action Identifiers

To permit USERA to hold jobs with an owner of USERB, use the following command:

RACF Security

PERMIT $$JOB2HLD.qname.USERB ACCESS(READ) ID(USERA) CLASS(FACILITY)

TopSecret Security

TSS PERMIT(USERA) ISMFAC($$JOB2HLD.qname.UDERB) ACC(READ)

ACF2/SAF Security

SET RESOURCE(CMF)
COMP
$KEY($$JOB2HLD.qname.USERB) TYPE(CMF)
 UID(USERA) ALLOW