System Display and Search Facility (SDSF) uses SAF (System Authorization Facility) to make its initial call for external security. If external security ignores the call, then SDSF internal security is used utilizing the ISFPARMS dataset.
Starting with z/OS 2.5, SDSF internal security cannot be used and setting up SAF external security is a requirement for SDSF. Possible errors seen when using internal SDSF security include ISF024I, ISF015I, ISF458E, or ISF452E
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
- 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.
Component : CA Top Secret for z/OS
There are two steps to convert SDSF ISPARMS to Top Secret security.
1. Convert ISFPRMxx into RACF commands using IBM provided REXX utility ISFACP.
2. Convert RACF commands to Top Secret commands
Below are examples of Top Secret commands typically used in the conversion from SDSF ISFPARMS.
Class SDSF Resources
The ISF.CONNECT.system Class SDSF resource profile.
To connect to the SDSF server, the user must have READ access to the ISF.CONNECT.system resource in the SDSF class.
An example of a rule to allow a user to connect to the SDSF server follows:
TSS PER(acid) SDSF(ISF.CONNECT.system) ACCESS(READ)
SERVER.NOPARM Class SDSF resource profile
When a user accesses SDSF, the SDSF client program attempts to connect to the SDSF address space (also referred to as the SDSF server). To connect to the SDSF server, the user must have READ access to the ISF.CONNECT.system resource in the SDSF class.
If the SDSF address space is not active, or if access to the ISF.CONNECT.system resource fails, SDSF allows for users to have limited functionality if they have READ access to the SERVER.NOPARM resource in the SDSF class so that ISFPARMS can be used instead of ISFPRMxx.
Class SDSF resource SERVER.NOPARM rule example:
TSS ADD(dept) SDSF(SERVER.)
TSS PER(acid) SDSF(SERVER.NOPARM) ACCESS(READ)
NOTE 1: If a user does not have access to SDSF(ISF.CONNECT.system), but does have READ access to SDSF(SERVER.NOPARM):
Message ISF458E Not authorized to connect to the SDSF server is received
The user can connect to the SDSF server and access the product in a limited capacity to resolve the issues.
NOTE 2: The resource check for the SERVER.NOPARM resource is only done if the the SDSF address space is not active, or if the validation for the ISF.CONNECT.system resource fails.
Class JESJOBS Resources
JESJOBS validation controls both job submit and job cancel activity. The resource name format is:
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.
TSS PER(ca7acid) JESJOBS(SUBMIT.prodnode.p)
TSS PER(ALL) JESJOBS(SUBMIT.testnode.p) ACTION(AUDIT)
TSS PER(ALL) JESJOBS(SUBMIT)
TSS PER(ALL) JESJOBS(SUBMIT.prodnode.p) ACCESS(NONE)
Class JOBCLASS Resources
There are two SAF calls available with JES2 and JES3 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 resources are added by creating IBMFAC class rules like the following example:
TSS PER(ALL) IBMFAC(JES.JOBCLASS.OWNER)
TSS PER(ALL) IBMFAC(JES.JOBCLASS.SUBMITTER)
Class JESSPOOL Resources
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, 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:
TSS PER(PRODCNTL) JESSPOOL(NODE1.prodid.prodjob.)
TSS PER(ALL) JESSPOOL(NODE1.prodid.) ACTION(AUDIT)
NOTE: If a user has access to the resource class SDSF resource ISFOPER.DEST.JES2 along with access to resource class SDSF resources ISFAUTH.DEST.LOCAL.DATASET.******** then SDSF will specify the RECVR parameter in the RACROUTE JESSPOOL call which will override JESSPOOL rules that would prevent access to JESSPOOL print jobs if the RECVR parameter matches the logonid accessing the JES2 datasets.
Class OPERCMDS Resources
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:
An example of a rule to allow anyone to issue JES2 display commands but limit other commands to systems people would be:
TSS PER(ALL) OPERCMDS(JES2.DISPLAY.)
TSS PER(SYSTEMS) OPERCMDS(JES2)
Class WRITER Resources
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:
An example of a rule protecting certain printers and NJE destinations follows:
TSS PER(SYSTEMS) WRITER(JES2.LOCAL.printer1)
TSS PER(ALL) WRITER(JES2.LOCAL.printer1)
TSS PER(PRODUID) WRITER(JES.NJE.prodnode )
TSS PER(ALL) WRITER(JES.) ACTION(AUDIT)
SDSF Panel Resources
An 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 over typeable 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 cancellation 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:
TSS PER(acid) SDSF(ISFCMD.DSP.ACTIVE.jesx) ACCESS(READ)
To protect the operator command:
TSS PER(acid) OPERCMD(jesx.CANCEL.type) ACCESS(UPDATE)
To protect the operator command of cancelling the job:
TSS PER(acid) OPERCMDS(MVS.CANCEL.type.jobname) ACCESS(UPDATE)
To protect access to the SYSLOG panel:
TSS PER(acid) SDSF(ISFCMD.ODSP.SYSLOG.) ACCESS(READ)
To protect initiators:
TSS PER(acid) SDSF(ISFINIT.Ixx.jesx) ACCESS(READ)
TSS PER(acid) SDSF(ISFINIT.Ixx.jesx) ACCESS(DELETE)
To protect the use of operator commands, but not check the actual command. (This includes the / in SDSF.)
TSS PER(acid) SDSF(ISFOPER.SYSTEM) ACCESS(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.Starting in z/OS 2.50, PERMITs must be created 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.
TSS PER(acid) SDSF(GROUP.ISFSPROG.SDSF) ACCESS(READ)
TSS PER(acid) SDSF(GROUP.ISFOPER.SDSF) ACCESS(READ)
TSS PER(acid) SDSF(GROUP.ISFUSER.SDSF) ACCESS(READ)
SDSF Class Resource Names for Overtypeable Fields (new in z/OS 2.50)
The resource names for the overtypeable fields are in the SDSF class or the GSDSF class and have a high level qualifier of ISFATTR. A user must have UPDATE authority to the ISFATTR resource to overtype a field. See IBM z/OS SDSF Operation and Customization Tables of overtypeable fields for the resource names for each overtypeable field.
SDSF resource ISFATTR rule examples:
TSS PER(ALL) SDSF(ISFATTR.OUTPUT.DEST)ACCESS(READ)
TSS PER(SYSPROG) SDSF(ISFATTR.OUTPUT) ACCESS(UPDATE)