SDSF External Security with CA-ACF2

Document ID : KB000028218
Last Modified Date : 26/07/2018
Show Technical Document Details
Introduction:

Introduction:

System Display and Search Facility (SDSF) uses SAF to make its initial call for external security. If external security ignores the call, then SDSF internal security is used utilizing the ISFPARMS dataset.

The benefits of using the SAF interface for SDSF security is:
- Dynamic change of security resource rules
- Single image of security information
- Simple introduction of security philosophy
- Improved auditability
- Improved protection

SDSF interacts with SAF to control access to the following SDSF resources:
- SDSF panels
- SDSF authorized commands
- Use of the / command to issue MVS and JES2 commands and receive responses
- Overtypeable fields
- Destination names
- Operator authority by destination
- Initiators
- Printers
- Lines
- Nodes
- Offloaders
- Members of a MAS
- Scheduling environments
- WLM resources
- Jobs affected by action characters and overtypeable fields
- Output groups affected by action characters and overtypeable fields
- SYSIN/SYSOUT data sets for browsing and viewing
- MVS and JES2 commands that are generated by action characters and overtypeable fields
- Use of the server MODIFY command

SDSF resources are protected externally through the SDSF, WRITER, JESSPOOL, and OPERCMDS SAF resource classes. The SDSF resource class protects panels, overtypeable fields, MVS/JES line commands, initiators, lines, nodes, readers, job classes, and so forth. The WRITER class protects printers and punches. The JESSPOOL class protects Jobs, output groups, and SYSIN/SYSOUT data sets. The OPERCMDS class protects generated MVS/JES commands and server Modify commands. See the SDSF Customization and Security Guide for the full details.

By default, CA-ACF2 normally ignores these SDSF, WRITER, JESSPOOL and OPERCMDS SAF calls and has internally coded SAFDEFs set to IGNORE. To enable CA-ACF2 security for any of the SDSF resource, the corresponding internal SAFDEF has to be overridden by inserting a locally defined SAFDEF. The following SAFDEF records are examples of doing this for each resource class:

Instructions:

SET Control(GSO)
Insert SAFDEF.SDSF ID(SDSF)MODE(GLOBAL) RACROUTE(REQUEST=AUTH,CLASS=SDSF) REP
Insert SAFDEF.WRITER ID(WRITER) MODE (GLOBAL) RACROUTE(REQUEST=AUTH,CLASS=WRITER) REP
Insert SAFDEF.JESSPL ID(JESSPL) MODE (GLOBAL) RACROUTE(REQUEST=AUTH,CLASS=JESSPOOL) REP
Insert SAFDEF.OPRCMDS ID(OPRCMDS) MODE (GLOBAL) RACROUTE(REQUEST=AUTH,CLASS=OPERCMDS) REP

Note: After creating any of these SAFDEFs and refreshing the CA-ACF2 GSO SAFDEF records, vaidation for each of these resources is active. Before activating these classes, ensure that all of the necessary rules are in place to allow the desired accesses. Since CA-ACF2 defaults the resource classes used by SDSF to the generic type code of SAF, it is recommended that each protected class should map to its own unique type code to avoid confusion. This is done using the GSO CLASMAP record. The following are examples of setting each of the SDSF resource classes to its own unique type code:

SET Control(GSO)
Insert CLASMAP.SDSF RESOURCE(SDSF) RSRCTYPE(SDF) ENTITYLN(63)
Insert CLASMAP.WRITER RESOURCE(WRITER) RSRCTYPE(WTR) ENTITYLN(39)
Insert CLASMAP.JESSPL RESOURCE(JESSPOOL) RSRCTYPE(SPL) ENTITYLN(53)
Insert CLASMAP.OPRCMDS RESOURCE(OPERCMDS) RSRCTYPE(OPR) ENTITYLN(39)

Sample JESJOBS rule
JESJOBS validation controls both job submit and job cancel activity. The resource name format is:

SUBMIT.nodename.jobname.userid
CANCEL.nodename.userid.jobname

The following example shows a rule to allow only CA7 to submit production jobs on the production node (production jobs always start with the letter P). Anyone can submit production jobs on the test node, but they are logged. The “catch-all” rule lets users submit their own jobs.

$KEY(SUBMIT) T(job)
 prodnode.p-.-  UID(ca7lid)  ALLOW
 prodnode.p-.-  UID(*)       PREVENT
 testnode.p-.-  UID(*)       LOG
 -.-            UID(*)       ALLOW

Sample JOBCLASS rule
There are two SAF calls available with JES2 and JES3 two SAF that control the use of specific job classes in z/OS 2.1. These SAF calls are triggered by the existence of either of the following FACILITY class profiles.

JES.JOBCLASS.OWNER - Checks if the execution owner has access to the job class
JES.JOBCLASS.SUBMITTER - Checks if the submitting userid has access to the job class.
These profiles are added by creating FACILITY class rules like the following example:

$KEY(JES.JOBCLASS.OWNER) TYPE(FAC)
uid(-) allow

Sample JESSPOOL rule
Validation of the JESSPOOL resource class provides the ability to protect the JES2 and JES3 data sets that are generated when a job runs. JESSPOOL data sets include those created by JES such as joblog, JCL and allocation messages data sets, and user-created data sets such as SYSIN and SYSOUT.

The JESSPOOL resource name consists of a node name, userid, job name, job number, data set ID, and data set name. 

To create a JESSPOOL resource rule, issue the following commands:

$KEY(NODE1) TYPE(SPL)
 prodid.prodjob.- UID(prodcntl) ALLOW
 prodid.prodjob.- UID(-) PREVENT
 prodid.- UID(-) LOG

Sample OPERCMDS rule
System operator commands can be controlled through use of OPERCMDS validation. Users issuing commands can be signed-on consoles, SDSF users, TSO/E Extended MCS consoles, or NJE commands.

The resource name format is:

subsys.command.operand

An example of a rule to allow anyone to issue JES2 display commands but limit other commands to systems people would be:

$KEY(JES2) T(OPR)
 DISPLAY.-  UID(*)  ALLOW
 -          UID(systems) ALLOW

Sample WRITER rule
With WRITER validation, you can control where data is sent. This includes output to a printer, or jobs sent through NJE to another node. Examples of resource names are:

subsys.LOCAL.device
subsys.NJE.nodename
An example of a rule protecting certain printers and NJE destinations follows:

$KEY(JES2) T(WTR)
 LOCAL.printer1  UID(systems)  ALLOW
 LOCAL.-         UID(*)  ALLOW
 NJE.prodnode    UID(produid)  ALLOW
 NJE.testnode    UID(*)  ALLOW
 -               UID(*)  LOG

Activating SDSF External Security

SDSF issues a RACROUTE REQUEST=AUTH, CLASS=SDSF for resource entity SERVER.NOPARM to determine if SDSF will use external security or SDSF internal security(Fall-back to ISFPARMS in assembler format). If external security ignores the call, then SDSF internal security is used utilizing the ISFPARMS dataset.

To use SDSF external security the following example rule can used.
$KEY(SERVER) TYPE(SDF)
NOPARM UID(uid string) SERVICE(READ) ALLOW

A SDSF task often requires access authority to more than one class and resource name. In order to perform the task, a user must have proper authority to all of the required resources. For example, to overtype a field, a user must have access to the panel, to the overtypeable field, to the MVS or JES2 command that will be generated, and to the object (for example, the job, output group, initiator, or printer) being acted upon. The SDSF Customization and Security Guide shows these relationship for many different possibilities. Following is a specific example of rules based on the SDSF Customization and Security Guide needed to control the cancelation of a batch job from the Active jobs (DA) panel. Note the examples are assuming that each of the SDSF resource classes has been given its own unique type code.

To protect access to the DA panel:
$KEY(ISFCMD) TYPE(SDF)
DSP.ACTIVE.jesx UID(uid string) SERVICE(READ) ALLOW

To protect the operator command:
$KEY(jesx) TYPE(OPR)
CANCEL.type UID(uid string) SERVICE(UPDATE) ALLOW

To protect the operator command of canceling the job:
$KEY(MVS) TYPE(OPR)
CANCEL.type.jobname UID(uid string) SERVICE(UPDATE) ALLOW

Below are some more examples of protecting other resources in SDSF. The SDSF Customization and Security Guide has lists the SDSF resources that can are validated.

To protect access to the SYSLOG panel:
$KEY(ISFCMD) TYPE(SDF)
ODSP.SYSLOG. jesx UID(uid string) SERVICE(READ) ALLOW

To protect initiators:
$KEY(ISFINIT) TYPE(SDF)
Ixx.jesx UID(uid string) SERVICE(READ) ALLOW (to allow displays)
Ixx.jesx UID(uid string) SERVICE(DELETE) ALLOW (to allow updating or overriding)

To protect the use of operator commands, but not check the actual command:
$KEY(ISFOPER) TYPE(SDF)
SYSTEM UID(uid string) SERVICE(READ)

Setting up rules for SDSF Group Authorization:
If you do not assign a name to a group, SDSF generates one: ISF plus the index value of the group, in the format ISFnnnnn.

The ISFPARMS and statements shipped with SDSF use the following group names:
ISFSPROG for group 1 resource: GROUP.ISFSPROG.SDSF
ISFOPER for group 2 resource: GROUP.ISFOPER.SDSF
ISFUSER for group 3 resource: GROUP.ISFUSER.SDSF

You can assign a name to a group or use the above SDSF groups. Permits(rules) shold be create to allow users READ access to the appropriate SAF resource GROUP.group-name.server-name in the SDSF class. If the user is authorized
to the group, then the user is assigned to the group, regardless of whether he may be authorized to groups that occur later in ISFPARMS. If the user is not authorized to the group through the SAF profile, SDSF goes on to the next group.

To address the error you would need to code rules to allow user usera access to the appropriate group. A sample rule follows.

$KEY(GROUP) TYPE(SDF)
ISFSPROG.SDSF UID(uid string) SERVICE(READ) ALLOW
ISFOPER.SDSF UID(uid string) SERVICE(READ) ALLOW
ISFUSER.SDSF UID(uid string) SERVICE(READ) ALLOW

To control the actual operator command issued, SAF calls in the OPERCMDS class must be validated. This is documented in the CA-ACF2 Administrators Guide, Appendix C. Also, the SDSF Customization and Security Guide details the various operator commands issued from the different panels.

Instructions:
Please Update This Required Field