SDSF External Security with CA-ACF2

Document ID : KB000028218
Last Modified Date : 14/02/2018
Show Technical Document Details

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)

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.