Implementing External Security (SAF)

Enabling External Security in CA SYSVIEW is controlled by defining a SAF Entity Class in the External Security Section of an Internal Security Group. This allows for the possibility of turning on External Security for some users, but not others. The default SAF Class is NONE, meaning that no SAF calls are made. Even though External Security may be in use, users are still assigned to an Internal Security Group that is used to determine External Security settings.
Enabling External Security in CA SYSVIEW is controlled by defining a SAF Entity Class in the External Security Section of an Internal Security Group. This allows for the possibility of turning on External Security for some users, but not others. The default SAF Class is NONE, meaning that no SAF calls are made. Even though External Security may be in use, users are still assigned to an Internal Security Group that is used to determine External Security settings.
Create Test User Group
  1. Create a new Internal User Group by entering the SECURITY command and selecting User Groups.
  2. Select the AddGroup row and over-type AddGroup with a new group name (such as SAFTEST).
  3. Select the External Security Section for this new group and review the settings for each of the fields. See help for the External Security Section for a description of each field.
  4. Identify a User ID that can be used for testing and add it to the User IDs Section of the test group. For the rest of the sections, Commands, Jobnames, and so on, leave the default values as they are.
Run the SAF Generator Utility
Use the SAF Generator Utility to generate template profiles, or rule definitions, based on the external security manager you are using.
The sample SAF Generator JCL is located in
Ensure the parameters for the Entity Prefix, Entity Class, System, and Qualifier match what you have defined in the External Security Section for your test User Group.
Determine Entity Types to Bypass
Using the output from the SAF Generator Utility, review the SUSP entities. Use these entities to suspend SAF calls for the specific entity type. For example, if you want to be able to access a job on spool regardless of what type of job it is (STC, TSU, OTX, JOB, and so on), then you can permit access to the SV.SUSP.*.JTYP entity to suspend all SAF calls for JTYP. The SUSP entities are checked once when a user session is started.
Allowing access to the SV.SUSP.*.RESN entity suspends SAF calls to all RESN entity types. If you only want to suspend SAF calls to specific RESN entities, grant access to only SV.SUSP.*.RESN.resntype entities. The SV.SUSP.*.RESN entity is global for all RESN types. The RESN types are described in the help for Security Resources
Do not grant universal access to the RESN types you do not care about securing in lieu of suspending the calls as the former still makes the SAF call. When you have decided what types to suspend, permit your test User ID access to these entities.
Using Command Groups
Consider using Command Groups to authorize access to commands and subcommands. Using Command Groups has several benefits:
  • It reduces the number of SAF calls made by making a single call to validate access to the group as opposed to making a call every time a command contained in the group is issued.
  • The number of profiles, or rules, needed to be defined is significantly less.
Command Groups listed in the SAF Generator Utility are pre-defined ones shipped with CA SYSVIEW. They begin with the reserved prefix of 'GSV'. For the most part, the groups are defined in pairs where the suffix 'A' denotes alter-type commands. For example, the group GSVCICS contains all the CICS commands (including the alter commands). Group GSVCICSA contains only CICS alter commands. If you have users that belong to the same Internal Security Group and you want some to have all CICS commands, but others to not have access to the CICS alter commands, you attach both groups GSVCICS and GSVCICSA to their Internal Security Group in the Command Groups Section. Then permit access to both CICS Command Group profiles (see the SAF Generator output) for the users that should have access to all CICS commands, and only permit access to the GSVCICS profile for those that should not have CICS alter commands.
You can create your own user-defined Command Groups. Command Groups are carried forward to new releases of CA SYSVIEW when the Security Conversion Utility is run. We do not recommend that you alter the pre-defined ('GSV') Command Groups because the Security Conversion Utility does not migrate any changes made to these groups.
Command Field Checking
The ability to limit what fields or columns display for a command is possible using External Security. Although field checking is possible, we do not recommend it because it adds additional overhead by making a SAF call for each column appearing on the display every time the command is entered.
To enable field checking, access to the CHKF profile is needed. In addition, access to the following profiles is required:
SV.RESN.<sysid>.FIELD.cccccccc.ffffffff cccccccc is the command ffffffff is the field name
The Internal Security of CA SYSVIEW allows giving a user DISPLAY-ONLY access to a field whereas External Security cannot. External Security can only allow or deny access. There is no concept of a DISPLAY-ONLY field.
Command Field profiles or rules are not produced by the SAF Generator Utility as their use is not recommended.
Bypassing Job Name Checking
The CHKU profile can be used to bypass Job Name checking (JOBN) for jobs that match any of the following:
  • The job name begins with the user's ID.
  • The ID associated with the job matches the user's ID.
  • The job has a NOTIFY= coded on the job that matches the user's ID.
Allowing access to the CHKU profile is a simple way to allow a user access to their own jobs. The CHKU processing does not rely on NTFY or USER entity types, so if either (or both) of these entity types are suspended, it does not affect bypassing of job name checking using CHKU.
Action Codes
When a Job Name (JOBN) or Resource (RESN) is accessed and a user attempts to perform an action against the resource, an Action Code is assigned to indicate what the user is attempting to do. A SAF call is first made for the JOBN or RESN entity. If that access is permitted, a second call is made with the associated Action Code. If the action attempted by the user is altering or modifying a resource, then the SAF call made containing the Action Code requires UPDATE access.
For example, suppose a user on system CA31 attempts to delete job TESTJOB from the JOBSUM display, the following calls are made when the delete line command is issued:
SV.JOBN.CA31.TESTJOB 1st call requiring READ access SV.JOBN.CA31.TESTJOB.AC.DEL 2nd call requiring UPDATE access
All of the JOBN and RESN Action Codes are documented in Controlling Access Using SAF.
Optionally, Action Codes can be enabled for USER calls if access is permitted to the CHKA entity. Action Codes for USER entities are the same as JOBN Action Codes. The SAF Generator Utility doesn't provide sample Action Code profiles. If you plan to use Action Codes, we recommend that you permit access to these entities using the generic profiles generated by the utility, then create an explicit profile for any restricted actions.
Enabling WARN Mode
WARN mode provides a means to trace SAF calls being made when External Security is enabled. WARN mode can be enabled by permitting access to:
to trace only specific entity type calls, or by granting access to:
to trace all SAF calls made by the user.
The trace is in the form of a WTO message that appears in the JES job log of the user's TSO session or in the CA SYSVIEW User address space, depending on what interface they are logged on to.
Trace messages can be enabled dynamically as well by entering a SET DEBUG4 X10 command from your CA SYSVIEW session. A SET DEBUG4 X00 disables the trace messages.
If the TSO or ISPF interface is being used, the trace message will also be TPUT back to the user's screen if WTPMSG is set in the TSO profile.
For initial testing, permit your test User ID access to the WARN mode entity.
Your test User ID should now have been granted access to all of the SUSP entities that you want to bypass and also be in WARN mode. You now need to permit access to all the resource types that you do want to check. For example, suppose you suspended checks for NTFY, USER, WTRN, JQUE, JTYP, ENV, and DDNM on system CA31 by permitting access to:
You will need to give access to CMND and SUBC (or use Command Group) profiles, RESN profiles, and JOBN profiles. The WARN mode trace messages can be used to fine-tune the access  requirements. Once you are satisfied with the access, WARN mode access should be removed.
SAF Statistics
SAF statistics are provided in the SESSION_LOGOFF Audit Event. This event must be active on the AUDITDEF display to get statistics. SAF statistics will only be generated for user sessions where External Security was active.
Section: SAF Statistics SAF calls made 1012 SAF calls avoided 3267 --- Total SAF calls --- 4279 JQUE calls 0 JTYP calls 0 NTFY calls 1074 USER calls 1410 JOBN calls 1410 DDNM calls 0 WTRN calls 0 RESN calls 345 CMND calls 10 SUBC calls 0 Other calls 30 Access Entity Table (AET) size 256K SAF CPU time 0.101173 SAF elapsed time 0.765851 SAF exit CPU time 0.000000 SAF exit elapsed time 0.000000