Control-D and Control-V Security

This chapter describes the procedure used to implement the Control‑D and Control‑V security interface. Review the explanations below on the elements that are protected in Control‑D and Control‑V, and then proceed to the step-by-step instructions.

For more information about the Control-D security (CTDSExx) modules discussed in this chapter, see also the descriptions of the corresponding IOA security exits from the IOA SAMPEXIT library, as discussed in the INCONTROL for z/OS Administrator Guide. For example, for more information about the CTDSE01 security module, see also the description of the CTDX001 security exit.

Protecting Control‑D and Control‑V Elements

The Control‑D and Control‑V security interface protects the following Control‑D and Control‑V elements.

• Ordering missions to the Active Missions file

• Access to decollated sysouts

• Access to and use of the Active Missions file

• Controlling the printing of reports by immediate print requests

• Use of ControlV Quick Access features

• Use of ControlV Indexing features

• Use of ControlD Delivery

• Controlling Online Viewing:

  • Use of the Recipient Tree definition

  • Using various rulers

  • Filter the list of reports

  • Access to reports

Ordering Missions

Each Control‑D mission is defined with an OWNER parameter. OWNER is the user ID to which this mission belongs. If a user requests to order a mission, the user must have the authorization to access the owner of the mission. The CTDSE01 Control‑D security module verifies that the current user has the authorization to order the mission, using the owner field of the mission.

Accessing Sysouts that Are Decollated

When a report decollating mission is ordered, the CTDSE01 Control‑D security module verifies that the user who ordered the mission is authorized to access the sysouts of the jobs that are decollated by this mission.

Accessing and Using of the Mission Status Screen (Screen A)

The Mission Status screen lists the active missions currently handled by Control‑D and their status. The user can issue inquiries about a mission within the list or change its status. the CTDSE08 Control‑D security module verifies the user’s authorization to perform actions (delete, rerun, zoom, and so on) on missions displayed in the Mission Status screen.

Updating Mission Status in Batch Mode

A user’s authority is verified when the user requests to run missions in batch mode. The CTDSE08 Control‑D security module verifies the user’s authority to change the mission status (RESTORE or BACKUP) in the Active Mission file.

Filtering the List of Reports in the User Screen (Screen U)

The User screen (Screen U) of Control‑D enables the user to view reports online. When the user enters Screen U, only the reports for which the user has access are listed.

The CTDSE04 Control‑D security module controls access to User Report List screens. When a user specifies selection criteria for reports, the list of reports that the user is allowed to see is displayed. The list can contain reports that belong to the user and reports of other users that this user is allowed to see. A user can view only the decollated portion of any report that the user is authorized to view.

For information about setting up security definitions, see the description of Exit CTDX004 in the INCONTROL for z/OS Administrator Guide.

Using Recipient Tree Definitions

The Recipient Tree is a major security mechanism in Control‑D that defines how reports are distributed to users. The tree is defined in one or more library members, and allocated by DD statement DATREE. The current user’s authority is checked to determine if the user is allowed to use the tree definition. If a user defines a tree with multiple members, the security module checks that each member is authorized for use. The tree is protected by IOASE32 and the user must have authorization to it to update it.

Accessing Reports

The CTDSE04 Control‑D security module verifies that the user is authorized to perform an operation on a report, such as viewing the report, masking the report, printing the report, and so on. Although online users can only access reports for which they are authorized, access to a specific report is also verified by checking the user’s authority to print the report, change the ruler, delete the report, and so on.

Limiting the Number of Pages Sent to Spool on Immediate Print Requests

Immediate printing requests can be restricted such that users are authorized to print reports with a specified number of pages. A check is performed to control the size of the report that a user is authorized to print using the immediate print request. There are three ranges of page numbers (defined as MIN, MID and MAX) that verify a user’s authority to print a report. All users are authorized to print a report if the number of pages to be printed is less the MIN value. Users can be authorized to print according to a page range between MIN and MID, MID and MAX, or above MAX.

Accessing CDAM Files

When a CDAM file is accessed by a user in Screen U, the user’s authority to access the CDAM file is checked by the CTDSE04 security module. This check is performed only if the DCDAMCHK installation parameter is set to YES during the implementation of Control‑D security.

Accessing Reports by Control‑D/Page On Demand

The CTDSE24 Security module is called to control access to the Control‑D Active User Report file and the Control‑V Migrated User Report file from Control‑D/Page On Demand. The mainframe logon user ID specified in the Control‑D/WebAccess Server Communication Setup menu is passed to this module. The associated user exit is CTDX024.

Using Control‑D Delivery

If Control‑D Delivery is installed, the CTDSE26 Control‑D security module verifies if the user is authorized to it as well as its various functions.

Control-D and Control-V Basic Definition Security Calls

Table 42 Control‑D and Control‑V Basic Definition Security Calls

Control-D and Control-V Extended Definition Security Calls

Table 43 Control‑D and Control‑V Extended Definition Security Calls

a See “Filtering the List of Reports in Screen U”, in Control-D and Control-V Security.

b This check is performed only if parameter DCDAMCHK is set to YES.

c If parameter DGLBRULR is set to YES, the ruler name is used instead of the Global Ruler owner.

d The values MIN, MID and MAX are set during Control-D security implementation using parameters DPAGMIN, DPAGMID and DPAGMAX.

Implementing Control-D and Control-V Security

This section details the steps required to implement the Control‑D security interface.

The Control-D 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.

The Control‑D security interface cannot be implemented until IOA security is installed. Verify that IOA security is implemented before implementing Control‑D security.

To install the Control-D security interface

1. Enter the main ICE screen.

2. Select Customization.

3. Enter CTD in the Product field.

4. Select Security Customization.

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

Step 1. Implement Control-D Security

Perform the following steps to implement Control‑D security.

Step 1.1. Grant Access Permissions

1. Collect the data you need to define the INCONTROL entities and user authorizations to the security product.

2. In ICE run the steps "ControlD Security Definitions" and "Functions Security Definitions" to create two sample jobs.

3. Enter the above security definitions into the sample jobs just created and save the jobs in the INSTWORK library.

4. Submit the jobs to define security to IOA and ControlD.

Step 1.2. Customize Security Parameters

Perform the steps in ICE for all the required parameters, as follows:

Table 44 ICE Parameters

The following parameters determine the number of pages a user is authorized to print using the immediate print request:

Table 45 Page Authorization Parameters

Table 46 ICE Definition Parameters

Table 47 Mode Definition Parameter

Step 1.3. Save Security Parameters into Product

This step saves all the security parameters specified for Control‑D. When this step completes, the Status column is automatically updated to COMPLETE.

Step 2. RACF Security Definitions (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 2.1 Control-D Security Definitions

Select this step to edit member CTDSRAC2 in the IOA INSTWORK library

Perform the following steps to define the required permissions:

1. Associating users with Extended Definition mode.

   1. Add the following commands to define the $$CTDEDM entity and authorize users to use this entity.

   2. Define the entity $$CTDEDM.qname as follows:

      Copy

      RDEFINE FACILITY $$CTDEDM.qname UACC(NONE)

   3. Authorize USERA to Extended Definition mode as follows:

      Copy

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

2. Submit the job for execution.

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

   Scan the output of the job for information and error messages. All job steps must end with a condition code of 0.

Step 2.2 Function Security Definitions

Select this step to edit the CTDSRAC3 member in the IOA INSTWORK library. This job contains various definitions for Control‑D. Review the definitions and modify according to your site's requirements.

Step 2.3 Control Program Access to Datasets

Select this step to edit the CTDSRAC4 member in the IOA INSTWORK library. This member contains a sample of the definitions required to define Program Pathing access authorizations to Control‑D datasets.

Review the definitions and modify according to the requirements of your site.

WARNING: BMC recommends that the security administrator first read Limiting Access to Specific Programs and the IBM Resource Access Control Facility Security Administrator’s Guide before submitting this job.

Step 3. TopSecret Security Definitions (Optional)

Step 3.1 Control-D Security Definitions

Select this step to edit member CTDSTSS2 in the IOA INSTWORK library

1. Define ControlD to the TopSecret Facility Matrix.

   CTDSTSS2 contains the necessary command to dynamically define ControlD in TopSecret Facility Matrix.

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

      Copy

      TSS MODIFY FAC(USER3=NAME=CTD)

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

   2. To permanently define the facility, update the TopSecret parameter member. This member is usually called TSSPARM0.

   3. Copy the ControlD facility definition from member CTDSTSS5 in the IOA INSTWORK library to member TSSPARM0.

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

2. Define ControlD ACID to TopSecret.

   Change the value of parameter DEPT from sec-administrator-dept to the appropriate ACID:

   Copy

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

3. Define ControlD started tasks to TopSecret.

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

   Copy

   TSS ADD(STC) PROC(CONTROLD) ACID(CTD)
   TSS ADD(STC) PROC(CTDPRINT) ACID(CTD)
   TSS ADD(STC) PROC(CTDNDAY) ACID(CTD)

4. Allow ControlD ACID to ControlD datasets.

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

   Connect the appropriate profile to the ControlD ACID in the following command:

   Copy

   TSS ADD (CTD) PROF (profile-name)

5. Define ControlD entities and user authorizations to TopSecret.

   For more information about how to define ControlD entities and user authorizations to TopSecret, see Control-D and Control-V Basic Definition Security Calls, and Control-D and Control-V Extended Definition Security Calls.

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

   Copy

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

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

   All entity names for each ControlD protected element appear in Control-D and Control-V Basic Definition Security Calls for Basic Definition mode and Control-D and Control-V Extended Definition Security Calls for Extended Definition mode.

6. Associate users with Extended Definition modes.

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

   Copy

   TSS PERMIT (USERA) IBMFAC($$CTDEDM.qname) ACC(NONE)

   Modify USERA to the UID of ControlD installer.

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

7. Authorize the ControlD installer to use ControlD facilities

   Customize the following command to authorize USERA access ControlD as follows:

   Copy

   TSS ADD(USERA) IBMFAC($$CTD)

   Modify USERA to the user ID of the ControlD installer.

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

   Copy

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

8. Submit the job.

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

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

Step 3.2 Function Security Definitions

Select this step to edit the CTDSTSS3 member in the IOA INSTWORK library. This job contains various definitions for Control‑D. Review the definitions and modify according to your site's requirements.

Step 3.3 Control Program Access to Datasets

Select this step to edit the CTDSTSS4 member in the IOA INSTWORK library. This member contains a sample of the definitions required to define Program Pathing access authorizations to Control‑D datasets.

Review the definitions and modify according to your site’s requirements.

WARNING: BMC recommends that the security administrator first read Limiting Access to Specific Programs and the TopSecret Implementation Guide before submitting this job.

Step 3.4 Define CTD to TopSecret Facility Matrix (Optional)

Select this step to edit the CTDSTSS5 member in the IOA INSTWORK library. Perform the following steps to define Control-D in the TopSecret Facility Matrix:

1. Modify USER3 in the Facility definition command to a free entry in the Facility Matrix, with the following command:

   Copy

   TSS MODIFY FAC(USER3=NAME=CTD)

2. Copy modified member CTDSTSS5 into TSSPARM0.

Step 4. ACF2 Security Definitions (Optional)

Step 4.1 Control-D Security Definitions

Select this step to edit member CTDSSAF2 in the IOA INSTWORK library

1. Define ControlD started tasks under ACF2.

   1. Define the ControlD started tasks as a valid started task under ACF2 (CONTROLD, CTDPRINT, CTDNDAY).

   2. Add the multi-user address space (MUSSAS) parameter to the logon ID record that is created for the ControlD started task.

   If the site uses more than one Control‑D monitor, parameter MUSSAS must be added to all the logon ID records previously created.

2. Associating users with extended definition mode.

   Define and authorize the entity $$CTDEDM.qname to ACF2 using the following command:

   Copy

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

3. Define entities and user authorizations to CAACF2/SAF.

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

   Copy

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

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

   Change USERA to the UID string of the ControlD installer.

   All entity names for each ControlD protected element appear in Control-D and Control-V Basic Definition Security Calls for Basic Definition mode and Control-D and Control-V Extended Definition Security Calls for Extended Definition mode.

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

4. Submit the job.

   This job must be run under a user of an ACF2 administrator who has authorization 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 of0.

Step 4.2 Function Security Definitions

Select this step to edit the CTDSSAF3 member in the IOA INSTWORK library. This job contains various definitions for Control‑D. Review the definitions and modify according to your site's requirements.

Step 4.3 Control Program Access to Datasets

Select this step to edit the CTDSSAF4 member in the IOA INSTWORK library. This member contains a sample of the definitions required to define Program Pathing access authorizations to Control‑D datasets.

Review the definitions and modify according to your site’s requirements.

BMC recommends that the security administrator first read Limiting Access to Specific Programs and the CA-ACF2 Administrator’s Guide before submitting this job.

Control-D Security Interface Modules

This section describes the Control‑D security interface modules.

Module CTDSE01

The CTDSE01 module is the security module of Control‑D Exit 1 (CTDX001). This module verifies that the user is authorized to order a mission. A check is performed to verify if the current user is allowed to order missions on behalf of the user ID specified in the owner field of the mission definition.

If the user ID is the same as the owner ID, no security check is performed.

Basic Definition Mode

Use of Recipient Tree Definition

The user’s authority to use a certain dataset specified under the DATREE DD is checked with the following entity:

$$TREE.dsn.member

where

• dsn is the dataset name of a library referenced by DD statement DATREE.

• member is the PDS member referenced by the DD statement.

For each dataset concatenated in DD statement DATREE, the security module is called once and checks each statement with the above entity.

The dataset name is truncated to 23 characters.

To permit USERA to use a DSN set to library‑name(member) in the DATREE DD, use the following commands:

For RACF:

RDEFINE FACILITY $$TREE.dsn.member UACC(NONE)
PERMIT $$TREE.dsn.member ACCESS(READ) ID(USERA) CLASS(FACILITY)

For TopSecret:

TSS ADD(system-dept) IBMFAC($$TREE)
TSS PERMIT(USERA) IBMFAC($$TREE.library.member-name) ACC(READ)

For ACF2/SAF:

SET RESOURCE(CMF)
COMP
$KEY($$TREE.dsn.member-name) TYPE(CMF)
 UID(USERA) ALLOW

Access a Report Under Screen U

When the user attempts to specify an action on a certain report (for example, view, ruler change, print), the entity checked is $$CTDACT.qname.userid where userid is the user name related to the report being accessed. There is no distinction between the different actions that can be specified. The user is either allowed to do anything with the report, or completely denied access to the report.

To permit USERA to perform actions to the reports of USERB, use the following command:

For RACF:

RDEFINE FACILITY $$CTDACT.qname.USERB UACC(NONE)
PERMIT $$CTDACT.qname.USERB ACCESS(READ) ID(USERA) CLASS(FACILITY)

For TopSecret:

TSS ADD(system-dept) IBMFAC($$CTDACT)
TSS PERMIT(USERA) IBMFAC($$CTDACT.qname.USERB) ACC(READ)

For ACF2/SAF:

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

Limit Immediate Print of Reports

When the user requests immediate print for a report, and the number of pages for the report is more than DPAGMIN, an additional entity is checked. The entity checked is:

Table 49 Report Limits

Extended Definition Mode

When the order is for a printing mission, the entity checked is $$PRTORD.qname.owner where owner is the owner ID specified in the printing mission definition.

RACF Security

The commands to permit USERA to order a printing mission with an owner of USERB are:

RDEFINE FACILITY $$PRTORD.qname.USERB UACC(NONE)
PERMIT $$PRTORD.qname.USERB CLASS(FACILITY) ID(USERA) ACC(READ)

TopSecret Security

When the order is for a printing mission, the entity checked is $$PRTORD.qname.owner, where owner is the owner ID specified in the printing mission definition.

The commands to permit USERA to order a printing mission with an owner of USERB are:

TSS PERMIT(USERA) IBMFAC($$PRTORD.qname.USERB) ACC(READ)

ACF2/SAF Security

When the order is for a printing mission, the entity checked is $$PRTORD.qname.owner, where owner is the owner ID specified in the print mission definition.

The commands to permit USERA to order a printing mission with an owner of USERB are:

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

The following entities are checked for orders in all security products:

Table 48 CTDSE01 Entity Checking

Module CTDSE04

The CTDSE04 module is the security module of the CTDX004 Control‑D Exit. This module builds a filtered list of reports displayed on the user’s screen and verifies the user’s authority to perform actions in the Control‑D User Report List screen (option U in the IOA Primary Option menu).

This module verifies that

• the user is authorized to use the Recipient Trees defined under ddname DATREE.

• the filtered list of reports applies only to those reports for which the user has authorization.

• the user is authorized to perform a specific action (print, delete, and so on) on a certain report.

• users are not authorized to print very long reports using immediate print requests.

• under the MASKRUL function, the end user is authorized during the Save/Delete/Off/Apply operations for the Mask Ruler, and during the View and Print operations for the corresponding report via the U-screen.

• if the end user does not have security permissions, the Mask ruler will be applied. (If the end user does have security permissions, then the user has the option of deciding whether the Mask ruler is applied or not.)

• in the case of Mask rulers only, if the entity does not exist, the security permissions will not be applied even if the Tolerance parameter is set to YES.

Filtering of the report list is built by scanning the Recipient Tree without any interaction with the security product. For more details, see "Filtering the List of Reports in the User Screen" in Control-D and Control-V Security. The CLASS checked is FACILITY (unless otherwise specified). The entity used to check authorization depends on if Basic Definition mode or Extended Definition mode is used.

Basic Definition Mode

Use of Recipient Tree Definition

The user’s authority to use a certain dataset specified under the DATREE DD is checked with the following entity:

$$TREE.dsn.member

where

• dsn is the dataset name of a library referenced by DD statement DATREE.

• member is the PDS member referenced by the DD statement.

For each dataset concatenated in DD statement DATREE, the security module is called once and checks each statement with the above entity.

The dataset name is truncated to 23 characters.

To permit USERA to use a DSN set to library‑name(member) in the DATREE DD, use the following commands:

For RACF:

RDEFINE FACILITY $$TREE.dsn.member UACC(NONE)
PERMIT $$TREE.dsn.member ACCESS(READ) ID(USERA) CLASS(FACILITY)

For TopSecret:

TSS ADD(system-dept) IBMFAC($$TREE)
TSS PERMIT(USERA) IBMFAC($$TREE.library.member-name) ACC(READ)

For ACF2/SAF:

SET RESOURCE(CMF)
COMP
$KEY($$TREE.dsn.member-name) TYPE(CMF)
 UID(USERA) ALLOW

Access a Report Under Screen U

When the user attempts to specify an action on a certain report (for example, view, ruler change, print), the entity checked is $$CTDACT.qname.userid where userid is the user name related to the report being accessed. There is no distinction between the different actions that can be specified. The user is either allowed to do anything with the report, or completely denied access to the report.

To permit USERA to perform actions to the reports of USERB, use the following command:

For RACF:

RDEFINE FACILITY $$CTDACT.qname.USERB UACC(NONE)
PERMIT $$CTDACT.qname.USERB ACCESS(READ) ID(USERA) CLASS(FACILITY)

For TopSecret:

TSS ADD(system-dept) IBMFAC($$CTDACT)
TSS PERMIT(USERA) IBMFAC($$CTDACT.qname.USERB) ACC(READ)

For ACF2/SAF:

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

Limit Immediate Print of Reports

When the user requests immediate print for a report, and the number of pages for the report is more than DPAGMIN, an additional entity is checked. The entity checked is:

Table 49 Report Limits

Examples

For RACF:

To allow USERA to immediately print a report of any size, use the following commands:

RDEFINE FACILITY $$PAGI* UACC(NONE)
PERMIT $$PAGI* CLASS(FACILITY) ID(USERA) ACCESS(READ)

To permit USERA to print reports that do not exceed the DPAGMAX number of pages, use the following commands:

RDEFINE FACILITY $$PAGII* UACC(NONE)
PERMIT $$PAGII* ID(USERA) CLASS(FACILITY) ACCESS(READ)

For TopSecret:

To allow USERA to immediately print a report of any size, use the following commands:

TSS ADD(system-dept) IBMFAC($$PAGI)
TSS PERMIT(USERA) IBMFAC($$PAGI) ACC(READ)

For ACF2/SAF:

To allow USERA to immediately print a report of any size, use the following commands:

SET RESOURCE(CMF)
COMP
$KEY($$DPAGI**) TYPE(CMF)
 UID(USERA) ALLOW

To permit USERA to print reports that do not exceed the DPAGMAX number of pages, use the following commands:

SET RESOURCE(CMF)
COMP
$KEY($$DPAGII*) TYPE(CMF)
 UID(USERA) ALLOW

Extended Definition Mode

Use of Recipient Tree Definition: The entity $$TREE.dsn.member is used to verify that the user is authorized to use a dataset referenced by DD statement DATREE.

where

• dsn is the dataset name of a library specified in DD statement DATREE.

• member is the PDS member referenced in the DD statement.

The security module is called once for each dataset concatenated in DD statement DATREE and checks each one with the above entity.

If the library name is longer than 23 characters, it is truncated to 23 characters. To permit USERA to use a member DSN set to library‑name(member) referenced in DD statement DATREE, use the following commands:

For RACF:

RDEFINE FACILITY $$TREE.library.member UACC(NONE)
PERMIT $$TREE.library.member ACCESS(READ) ID(USERA) CLASS(FACILITY)

For TopSecret:

TSS PERMIT(USERA) IBMFAC($$TREE.library.member-name) ACC(READ)

For ACF2/SAF:

SET RESOURCE(CMF)
COMP
$KEY($$TREE.dsn.member-name) TYPE(CMF)
 UID(USERA) ALLOW

Security by report name: Reports appearing in the report list can be controlled based on the report names in the User Screen (Screen U). Security by report name works only under Control-D extended security mode. To switch on, set the REPNCHK parameter to Y, as discussed in Step 1. Implement Control-D Security.

To give permissions for end users to see reports in the report list, the following entity must be defined in the SAF (System Access Facility):

$$RPNASR.qname.report name

The maximum length of the report name is 50 characters. Such entities must be defined under class that accept entities which are 68 characters long. The name of this class must by specified in the IOAXCLAS parameter of IOASECP section in the SECPARM.

$$RPNASR entities must be defined in SAF in uppercase.

IOAX037 exit is used to convert these entities to uppercase.

By default, IOAX037 contains tables for the English language.

Report names in SAF entities must not contain blank characters. By default, blank characters are replaced by underscore characters. You can use the REPSPACE parameter to choose a different character, as discussed in Step 1. Implement Control-D Security.

Access a Report Under Screen U

The user’s authority to issue an action (update, delete, and so on) on a certain report is checked with the following entity:

Table 50 Report Access

Control‑V:

Table 51 Control‑V Features

In the above entities, userid is the user ID to whom the report belongs.

To permit USERA to view (browse) a report that belongs to USERB, use the following commands:

For RACF:

RDEFINE FACILITY $$VIEWCO.qname.USERB UACC(NONE)
PERMIT $$VIEWCO.qname.USERB ACCESS(READ) ID(USERA) CLASS(FACILITY)

For TopSecret:

TSS ADD(system-dept) IBMFAC($$VIEWCO.qname.USERB)
TSS PERMIT(USERA) IBMFAC($$VIEWCO.qname.USERB) ACC(READ)

For ACF2/SAF:

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

Limit Immediate Print of Reports

When user requests an immediate print for a report, and the number of pages for the report is more than DPAGMIN, an additional entity is checked. The entity structure is as follows:

Table 52 Report Limits

For RACF:

RDEFINE FACILITY $$PAGI* UACC(NONE)
PERMIT $$PAGI* CLASS(FACILITY) ID(USERA) ACCESS(READ)

RDEFINE FACILITY $$PAGII UACC(NONE)
PERMIT $$PAGII ID(USERA) CLASS(FACILITY) ACCESS(READ)

For TopSecret:

TSS ADD(system-dept) IBMFAC($$PAGI)
TSS PERMIT(USERA) IBMFAC($$PAGI) ACCESS(READ)

TSS PERMIT(USERA) IBMFAC($$PAGI) ACCESS(READ)

For ACF2/SAF:

SET RESOURCE(CMF)
COMP
$KEY($$PAGI**) TYPE(CMF)
 UID(USERA) ALLOW

SET RESOURCE(CMF)
COMP
$KEY($$PAGII*) TYPE(CMF)
 UID(USERA) ALLOW

Module CTDSE08

The CTDSE08 Control‑D security module verifies the user’s authority to access the Active Missions screen (screen A) and perform actions (rerun, hold, delete, and so on) on missions displayed in this screen.

The CTDSE08 security module functions are performed under two modes of operation:

• Online: Active Missions screen (screen A).

• Batch: For example, a restore mission resets the status of the restore mission from "restore in process" to "ended."

IOA checks authorization:

• The class checked is FACILITY.

• The entity checked depends under what mode (Online Basic Definition, Online Extended Definition, or Batch) the module is invoked.

Online Basic Definition Mode

Initial Entry to Screen A

IOA checks authorization:

• The class checked is FACILITY.

• The entity checked is $$CTDPNLA.qname

No distinction is made between the authority to perform actions on missions that are present in the Active Missions file, and the authority to submit a job.

This is equivalent to asking if the current user has the authority to submit jobs with USER parameter equal to that of the mission’s owner. If a user is authorized to submit a job on behalf of other users, then the user is also authorized to perform the specific action (hold, free, delete, and so on) on missions belonging to other users. If the mission’s owner is the current user, the security check is bypassed.

For RACF:

When an action is performed on missions that are present in the Active Missions file, the entity checked is owner.SUBMIT using the SURROGAT class.

For TopSecret:

When an action is performed on missions that are present in the Active Missions file, the TopSecret Application Interface module (TSSAI) is called with the following parameters:

Resource Class: ACIDCHK

Resource Name: ownerid

For ACF2/SAF:

When an action is performed on missions that are present in the Active Missions file, the entity checked is $SUBMIT.owner using the FACILITY class.

Extended Definition Mode

Initial Entry to Screen A

IOA checks authorization:

• The class checked is FACILITY.

• The entity checked is $$CTDPNLA.qname

Subsequent Operations in Screen A

The actions (hold, delete, rerun, and so on) are separated into different categories of access authority to the Active Missions screen (Screen A). The entity checked is $$MISxrrr.qname

where

• owner is the owner ID that is specified in the Mission Definition screen.

• x is a one digit action identifier.

• rrr is a three character identifier for each action (see the following table).

Table 53 CTDSE08 Action Identifiers

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

TSS PERMIT(USERA) IBMFAC($$MIS2HLD.qname.USERB) ACC(READ)

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

Batch

The entity checked is $$CTDRRST.qname.owner

This entity is checked for batch jobs (Control‑D and Control‑V backup and restore jobs and Control‑V migration jobs). In most cases, the batch jobs runs under the user ID of the Control‑D and Control‑V started tasks.

The user ID of the Control‑D started tasks as specified in the Control‑D installation procedure.

Use the following command to allow Control‑D to access this entity:

For RACF:

PERMIT $$CTDRRST.qname.* ACCESS(READ) ID(controld‑stc’s‑userid) CLASS(FACILITY)

For TopSecret:

TSS PERMIT(controld-acid) IBMFAC($$CTDRRST.qname) ACC(READ)

For ACF2/SAF:

SET RESOURCE(CMF)
COMP
$KEY($$CTDRRST.qname) TYPE(CMF)
 UID(userid) ALLOW

where userid is one or more Control‑D started tasks that are specified during Control‑D installation.

Module CTDSE24

The CTDSE24 module is the security module of Control‑D Exit CTDX024. This module is called when a request is made by Control‑D/Page On Demand to access the Control‑D Active User Report file or the Control‑V Migrated User Report file.

This module checks that

• the user’s authorization is according to the mainframe logon user ID specified in the ControlD/WebAccess Server Communication Setup menu.

• under the MASKRUL function, the end user is authorized during the Save/Delete/Off/Apply operations for the Mask Ruler, and during the View and Print operations for the corresponding report via ControlD/WebAccess Server.

• if the end user does not have security permissions, the Mask ruler will be applied. (If the end user does have security permissions, then the user has the option of deciding whether the Mask ruler is applied or not.)

• in the case of Mask rulers only, if the entity does not exist, the security permissions will not be applied even if the Tolerance parameter is set to YES.

This module builds a filtered list of reports displayed on the user’s screen, and verifies the user’s authority to perform actions from Control‑D/Page On Demand.

IOA verifies authorization for every action that is performed on a specific report. The CLASS checked is FACILITY (unless otherwise specified) and the entity used to check authorization depends on if Basic or Extended Definition mode is used.

Basic Definition Mode

The CTDSE24 security module retrieves security definitions from the Recipient Tree. The administrator can authorize Control‑D/Page On Demand users to view mainframe reports by adding the appropriate mainframe logon ID to the AUTHORIZE field in the recipient definitions in the Recipient Tree. These authorizations enable Control‑D/Page On Demand users to see the reports of these recipients using Control‑D/Page On Demand. For more information, see the Recipient Definition screen in the online facilities chapter of the Control‑D and Control V User Guide.

When a mainframe logon ID is entered in the AUTHORIZE field of a recipient definition, the authorized Control‑D/Page On Demand user can view all the reports of that recipient and descendants in the Recipient Tree. The same mainframe logon ID can be entered in the AUTHORIZE field of more than one recipient in the Recipient Tree.

The following rules apply to mainframe logon IDs entered in the AUTHORIZE field in a recipient definition:

• The specified logon ID is treated as a prefix if optional Wish WD2564 is set to YES in member IOADFLTC in the IOA MAC library.

• The specified mainframe logon ID can contain a number of "?" characters. This wildcard character indicates any single character.

Access a Report from Control‑D/Page On Demand

When the user requests an action (view, print) on a certain report, the entity checked is $$CTDASR.qname.userid, where userid is the user name related to the report being accessed.

There is no distinction between the different actions that can be specified. The user is either allowed to perform any valid action with the report or completely denied access to the report.

To permit USERA (the mainframe logon ID) to perform actions to the reports of USERB (the Control‑D recipient name), use the following command:

For RACF:

RDEFINE FACILITY $$CTDASR.qname.USERB UACC(NONE)
PERMIT $$CTDASR.qname.USERB ACCESS(READ) ID(USERA) CLASS(FACILITY)

For TopSecret:

RDEFINE FACILITY $$CTDASR.qname.USERB UACC(NONE)
PERMIT $$CTDASR.qname.USERB ACCESS(READ) ID(USERA) CLASS(FACILITY)

For ACF2/SAF:

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

Limit Immediate Print of Reports

When the user requests immediate print, and the report contains more than the minimum number of pages specified in parameter DPAGMIN, the following entity is checked to verify that the user is authorized to send the number of pages contained in the report to the printer:

Table 55 Print Limits

RDEFINE FACILITY $$PGASRI UACC(NONE)
PERMIT $$PGASRI CLASS(FACILITY) ID(USERA) ACCESS(READ)

RDEFINE FACILITY $$PGASRII UACC(NONE)
PERMIT $$PGASRII ID(USERA) CLASS(FACILITY) ACCESS(READ)

SET RESOURCE(CMF)
COMP
$KEY($$PGASRI) TYPE(CMF)
 UID(USERA) ALLOW

Extended Definition Mode

The CTDSE24 security module retrieves security definitions from the Recipient Tree. The administrator can authorize Control‑D/Page On Demand users to view mainframe reports by adding the appropriate mainframe logon ID to the AUTHORIZE field in the recipient definitions in the Recipient Tree. For information about how this is done, see Basic Definition Mode.

Reports appearing in the report list can be controlled based on the report names in Control-D/Page On Demand.

Security by report name works only under Control-D extended security mode. To switch on, set the REPNCHK parameter to Y, as discussed in Step 1. Implement Control-D Security.

To give permissions for end users to see reports in the report list, the following entity must be defined in the SAF (System Access Facility):

$$RPNASR.qname.report name

The maximum length of the report name is 50 characters. Such entities must be defined under class that accept entities which are 68 characters long. The name of this class must by specified in the IOAXCLAS parameter of IOASECP section in the SECPARM.

$$RPNASR entities must be defined in SAF in uppercase.

IOAX037 exit is used to convert these entities to uppercase.

By default, IOAX037 contains tables for the English language.

Report names in SAF entities must not contain blank characters. By default, blank characters are replaced by underscore characters. You can use the REPSPACE parameter to choose a different character, as discussed in Step 1. Implement Control-D Security.

Access a Report From Control‑D/Page On Demand

The user’s authority to issue an action (update, delete, and so on) on a certain report is checked with the following entities:

Table 56 Report Access

In the above entities, userid is the user ID to whom the report belongs.

To permit USERA (meaning, the mainframe logon ID) to view (browse) a report that belongs to USERB (meaning, the Control‑D recipient name), use the following command:

For RACF:

RDEFINE FACILITY $$VIEASR.qname.USERB UACC(NONE)
PERMIT $$VIEASR.qname.USERB ACCESS(READ) ID(USERA) CLASS(FACILITY)

For TopSecret:

To allow USERA to immediately print a report of any size, use the following commands:

TSS PERMIT(USERA) IBMFAC($$VIEASR.qname.USERB) ACC(READ)

For ACF2/SAF:

To allow USERA to immediately print a report of any size, use the following commands:

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

Limit Immediate Print of Reports

When the user requests immediate print, and the report contains more than the minimum number of pages specified in parameter DPAGMIN, the following entity is checked to verify that the user is authorized to send to the printer the number of pages contained in the report:

Table 57 Report Limits

For RACF:

RDEFINE FACILITY $$PGASRI UACC(NONE)
PERMIT $$PGASRI CLASS(FACILITY) ID(USERA) ACCESS(READ)

RDEFINE FACILITY $$PGASRII UACC(NONE)
PERMIT $$PGASRII ID(USERA) CLASS(FACILITY) ACCESS(READ)

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

For ACF2/SAF:

SET RESOURCE(CMF)
COMP
$KEY($$PGASRI) TYPE(CMF)
 UID(USERA) ALLOW

Module CTDSE28

The CTDSE28 module is the security module of Control-D Exit CTDX028. This module is called when a user attempts to enter to any option in screen DO (Control-D Objects) in the IOA primary menu, in addition this module checks the user’s authorization to create, save or delete a report clique or a resource set.

IOA verifies authorization for every action that is performed on a specific report clique or resource set. The CLASS checked is FACILITY (unless otherwise specified) and the entity used to check authorization depends on action the user attempts to do.

Access to option 1 of the DO screen (Report Clique)

When the user attempts to enter to this option the entity checked is $$CTDOBJ.qname.ENTRY.REPCLQ. To permit USERA (the mainframe logon ID) to enter to this option, use the following command:

For RACF:

RDEFINE FACILITY $$CTDOBJ.qname.ENTRY.REPCLQ UACC(NONE)
PERMIT $$CTDOBJ.qname.ENTRY.REPCLQ ACCESS(READ) ID(USERA)
CLASS(FACILITY)

For TopSecret:

TSS PERMIT(USERA) IBMFAC($$CTDOBJ.qname.ENTRY.
 REPCLQ)  ACC(READ)

For ACF2/SAF:

SET RESOURCE(CMF)
COMP
$KEY($$CTDOBJ.qname.ENTRY.REPCLQ) TYPE(CMF)
 UID(USERA) ALLOW

Access to option 2 of the DO screen (Resource Set)

When the user attempts to enter to this option, the entity checked is $$CTDOBJ.qname.ENTRY.RESSET. To permit USERA (the mainframe logon ID) to enter to this option use the following command:

For RACF:

RDEFINE FACILITY $$CTDOBJ.qname.ENTRY.RESSET UACC(NONE)
PERMIT $$CTDOBJ.qname.ENTRY.RESSET ACCESS(READ) ID(USERA)
CLASS(FACILITY)

For TopSecret:

TSS PERMIT(USERA) IBMFAC($$CTDOBJ.qname.ENTRY. RESSET)
 ACC(READ)

For ACF2/SAF:

SET RESOURCE(CMF)
COMP
$KEY($$CTDOBJ.qname.ENTRY.RESSET) TYPE(CMF)
 UID(USERA) ALLOW

To save a new report clique or a modified report clique

When the user attempts to create or to save a report clique the entity checked is $$CTDOBJ.qname.SAVE.report-clique-name.

To permit USERA (the mainframe logon ID) to perform this option use the following command:

For RACF:

RDEFINE FACILITY $$CTDOBJ.qname.SAVE.report-clique-name UACC(NONE)
PERMIT $$CTDOBJ.qname.SAVE.report-clique-name ACCESS(READ) ID(USERA)

CLASS(FACILITY)

For TopSecret:

TSS PERMIT(USERA) IBMFAC($$CTDOBJ.qname.SAVE.report-clique-name) ACC(READ)

For ACF2/SAF:

SET RESOURCE(CMF)
COMP
$KEY($$CTDOBJ.qname.SAVE.report-clique-name) TYPE(CMF)
 UID(USERA) ALLOW

To delete a report clique

When the user attempts to delete a report clique the entity checked is $$CTDOBJ.qname.DELETE.report-clique-name. To permit USERA (the mainframe logon ID) to perform this option use the following command:

For RACF:

RDEFINE FACILITY $$CTDOBJ.qname.DELETE.report-clique-name UACC(NONE)
PERMIT $$CTDOBJ.qname.DELETE.report-clique-name ACCESS(READ) ID(USERA)
CLASS(FACILITY)

For TopSecret:

TSS PERMIT(USERA) IBMFAC($$CTDOBJ.qname.DELETE.report-clique-name) ACC(READ)

For ACF2/SAF:

SET RESOURCE(CMF)
COMP
$KEY($$CTDOBJ.qname.DELETE.report-clique-name) TYPE(CMF)
 UID(USERA) ALLOW

To delete a resource set

When the user attempts to delete a resource set the entity checked is $$CTDOBJ.qname.DELETE.resource-set-name. To permit USERA (the mainframe logon ID) to perform this option use the following command:

For RACF:

RDEFINE FACILITY $$CTDOBJ.qname.DELETE.resource-set-name UACC(NONE)
PERMIT $$CTDOBJ.qname.DELETE.resource-set-name ACCESS(READ) ID(USERA)
CLASS(FACILITY)

For TopSecret:

TSS PERMIT(USERA) IBMFAC($$CTDOBJ.qname.DELETE.resource-set-name) ACC(READ)

For ACF2/SAF:

SET RESOURCE(CMF)
COMP
$KEY($$CTDOBJ.qname.DELETE.resource-set-name) TYPE(CMF)
 UID(USERA) ALLOW