When using external security, Application Performance Analyzer functions are protected using general resource profiles - defined in the default FACILITY class, or in a user-specified class that has been previously defined (it can be an existing class or a new class defined specifically for Application Performance Analyzer).
The profile name is specified as:
The optional high-level qualifier can be used to define generic rules for all members of a sysplex.
The MVS system name, as it applies to an observation, represents the system on which the observation was finally serviced. In a non-sysplex environment the system name is the same as the name of the system where the observation request was made.
In a sysplex environment, the intent of the system name is to control an observation request based on the target system or servicing system name, which prevents a user from adding an observation request that targets a job that will execute on a system to which that the user does not have access.
In determining the resource profile to be used for authorization, Application Performance Analyzer derives the system name based on the status of the observation, the action to be performed, and the sysplex options specified on the observation request. For observation requests that are to be scheduled or are in schedule status in which the target system is specified, the target system name is used. If the target system is specified as * or ALL, an attempt is made to evaluate the user's authority based on the current system name and the system names of the systems in the sysplex group - if authority cannot be determined definitively, the request is provisionally accepted and user authorization will be performed again when the request runs. For completed or active observations, the system name used will be the servicing system name. See Examples for specific examples of how Application Performance Analyzer derives the system name.
The action represents the type of access involved in the function being performed. The types of access are:
By default, all users have access to VIEW, UPDATE and DELETE any observation they create, as well as monitor their own TSO userid. Therefore, profiles do not need to be specified for a user to have access to their own observations. All other types of access are protected by default and must have a profile written for any user to have access to them. Access is denied if RACF denies access or if RACF cannot find an applicable profile.
The types of objects are:
The User ID or Job Name pattern follows standard RACF syntax and can be a full name, a name pattern, a partial name with an *, or just an * to indicate any name is acceptable. See the IBM z/OS Security Server RACF Security Administrator's Guide, (SA22-7683), for coding details on generic profiles.
For any authorization call, Application Performance Analyzer determines the profile name to be used based on the derived MVS system name, status, and action. The following table lists some of the values for these criteria and the resulting profile name in a sysplex group.
Status | System name | Action | RACF profile names |
---|---|---|---|
Complete | Servicing system name | New (line command) |
|
Submit |
|
||
Report/ Select |
|
||
Detail |
|
||
Delete |
|
||
Keep |
|
||
Administer Product |
|
||
Scheduled | Target system name specified | New (line command) |
|
Modify |
|
||
Detail |
|
||
Delete |
|
||
Scheduled | * or all specified | New (line command) |
|
Modify |
|
||
Detail |
|
||
Delete |
|
||
Active | Servicing system name | New (line command) |
|
Submit |
|
||
Detail |
|
||
Cancel |
|
||
RTM |
|
The following table provides examples of how a system name is derived. The examples assume the following:
User ID | Action | Logon system | Target system | Servicing system | Comments |
---|---|---|---|---|---|
DEV1 | Add new observation | SYSTEMD | SYSTEMD | n/a | Access granted based on target system. |
DEV1 | Add new observation | SYSTEMD | SYSTEMP | n/a | Access denied based on target system. |
DEV1 | Add new observation | SYSTEMD | * (any) | n/a | Access provisionally granted. Access will be checked again based on the system where the job finally executes. |
DEV1 | Delete completed observation | SYSTEMD | SYSTEMD | SYSTEMD | Access granted based on servicing system. |
DEV1 | Delete completed observation | SYSTEMD | * (any) | SYSTEMP | Access denied based on servicing system. |
DEV1 | Delete completed observation of DEV1 TSO session | SYSTEMD | SYSTEMP | SYSTEMP | Access granted. User is allowed to update observation that he owns. |
DEV1 | Delete scheduled observation owned by DEV2 | SYSTEMD | * (any) | n/a | Access granted. Since the system name is not known, SYSTEMD (the logon system) will be used to determine the resource profile name. |
DEV1 | Delete scheduled observation owned by DEV2 | SYSTEMD | SYSTEMD | n/a | Access granted. Target system used to determine the resource profile name. |
DEV1 | Modify scheduled observation | SYSTEMD | SYSTEMD | n/a | Access granted based on target system. |
DEV1 | Modify scheduled observation | SYSTEMD | * (any) | n/a | Access denied based on logon system and owner ADM1. |
DEV1 | Add new observation | SYSTEMP | SYSTEMD | n/a | Access granted based on target system. |
DEV1 | Add new observation | SYSTEMP | SYSTEMP | n/a | Access denied based on target system. |
DEV1 | Add new observation to measure DEV1's active TSO session | SYSTEMP | SYSTEMP | SYSTEMP | Access granted. User is allowed to measure his own TSO session. |
DEV1 | Delete completed observation owned by DEV2 | SYSTEMP | * (any) | SYSTEMP | Access granted based on servicing system. |
The following examples illustrate how to define RACF profiles based on the examples in the table above. The examples assume the following:
The following RACF commands define the resource profiles that are dependant on the MVS system name.
RDEFINE FACILITY SYSTEMD.VIEW.* UACC(NONE)
RDEFINE FACILITY SYSTEMD.UPDATE.* UACC(NONE)
RDEFINE FACILITY SYSTEMD.DELETE.* UACC(NONE)
RDEFINE FACILITY SYSTEMD.MEASURE.** UACC(NONE)
RDEFINE FACILITY SYSTEMD.MONITOR.** UACC(NONE)
RDEFINE FACILITY SYSTEMD.VIEW.DEV% UACC(NONE)
RDEFINE FACILITY SYSTEMD.UPDATE.DEV% UACC(NONE)
RDEFINE FACILITY SYSTEMD.DELETE.DEV% UACC(NONE)
RDEFINE FACILITY SYSTEMD.USE.DB2PLUS UACC(NONE)
RDEFINE FACILITY SYSTEMD.USE.IMSPLUS UACC(NONE)
RDEFINE FACILITY SYSTEMD.USE.WLMI UACC(NONE)
RDEFINE FACILITY SYSTEMD.USE.CICSPlus UACC(NONE)
RDEFINE FACILITY SYSTEMP.VIEW.* UACC(NONE)
RDEFINE FACILITY SYSTEMP.UPDATE.* UACC(NONE)
RDEFINE FACILITY SYSTEMP.DELETE.* UACC(NONE)
RDEFINE FACILITY SYSTEMP.MEASURE.** UACC(NONE)
RDEFINE FACILITY SYSTEMP.MONITOR.** UACC(NONE)
RDEFINE FACILITY SYSTEMP.VIEW.DEV1 UACC(NONE)
RDEFINE FACILITY SYSTEMP.VIEW.DEV2 UACC(NONE)
RDEFINE FACILITY SYSTEMP.UPDATE.DEV1 UACC(NONE)
RDEFINE FACILITY SYSTEMP.UPDATE.DEV2 UACC(NONE)
RDEFINE FACILITY SYSTEMP.DELETE.DEV1 UACC(NONE)
RDEFINE FACILITY SYSTEMP.DELETE.DEV2 UACC(NONE)
RDEFINE FACILITY SYSTEMP.USE.DB2PLUS UACC(NONE)
RDEFINE FACILITY SYSTEMP.USE.IMSPLUS UACC(NONE)
RDEFINE FACILITY SYSTEMP.USE.WLMI UACC(NONE)
RDEFINE FACILITY SYSTEMP.USE.CICSPlus UACC(NONE)
The following RACF commands permit users ADM1 and ADM2 to view, update, or delete any observations. The RACF commands also allow users ADM1 and ADM2 to measure or threshold-monitor any address space type in which SYSTEMD is the servicing system.
PERMIT SYSTEMD.VIEW.* CLASS(FACILITY) ID(ADMGRP) ACCESS(READ)
PERMIT SYSTEMD.UPDATE.* CLASS(FACILITY) ID(ADMGRP) ACCESS(READ)
PERMIT SYSTEMD.DELETE.* CLASS(FACILITY) ID(ADMGRP) ACCESS(READ)
PERMIT SYSTEMD.MEASURE.** CLASS(FACILITY) ID(ADMGRP) ACCESS(READ)
PERMIT SYSTEMD.MONITOR.** CLASS(FACILITY) ID(ADMGRP)ACCESS(READ)
The following RACF commands permit users DEV1 and DEV2 to view, update, or delete any observations owned by either DEV1 or DEV2 in which SYSTEMD is the servicing system. The RACF commands also allow users DEV1 and DEV2 to measure or threshold-monitor any address space type in which the target system or servicing system is SYSTEMD.
PERMIT SYSTEMD.VIEW.DEV% CLASS(FACILITY) ID(DEVGRP) ACCESS(READ)
PERMIT SYSTEMD.UPDATE.DEV% CLASS(FACILITY) ID(DEVGRP) ACCESS(READ)
PERMIT SYSTEMD.DELETE.DEV% CLASS(FACILITY) ID(DEVGRP) ACCESS(READ)
PERMIT SYSTEMD.MEASURE.** CLASS(FACILITY) ID(DEVGRP) ACCESS(READ)
PERMIT SYSTEMD.MONITOR.** CLASS(FACILITY) ID(DEVGRP) ACCESS(READ)
The following RACF commands permit all users to activate DB2Plus, IMSPlus, WLMI, and CICSI for observations in which the target system or servicing system is SYSTEMD.
PERMIT SYSTEMD.USE.DB2PLUS CLASS(FACILITY) ACCESS(READ)
PERMIT SYSTEMD.USE.IMSPLUS CLASS(FACILITY) ACCESS(READ)
PERMIT SYSTEMD.USE.WLMI CLASS(FACILITY) ACCESS(READ)
PERMIT SYSTEMD.USE.CICSPlus CLASS(FACILITY) ACCESS(READ)
The following RACF commands permit users ADM1 and ADM2 to view, update, or delete any observations. The RACF commands also allow users ADM1 and ADM2 to measure or threshold-monitor any address space type in which the servicing system is SYSTEMP.
PERMIT SYSTEMP.VIEW.* CLASS(FACILITY) ID(ADMGRP) ACCESS(READ)
PERMIT SYSTEMP.UPDATE.* CLASS(FACILITY) ID(ADMGRP) ACCESS(READ)
PERMIT SYSTEMP.DELETE.* CLASS(FACILITY) ID(ADMGRP) ACCESS(READ)
PERMIT SYSTEMP.MEASURE.** CLASS(FACILITY) ID(ADMGRP) ACCESS(READ)
PERMIT SYSTEMP.MONITOR.** CLASS(FACILITY) ID(ADMGRP) ACCESS(READ)
The following RACF commands permit users ADM1 and ADM2 to activate DB2Plus, IMSPlus, WLMI and CICSI for observation in which the target system or the servicing system is SYSTEMD.
PERMIT SYSTEMD.USE.DB2PLUS CLASS(FACILITY) ID(ADMGRP) ACCESS(READ)
PERMIT SYSTEMD.USE.IMSPLUS CLASS(FACILITY) ID(ADMGRP) ACCESS(READ)
PERMIT SYSTEMD.USE.WLMI CLASS(FACILITY) ID(ADMGRP) ACCESS(READ)
PERMIT SYSTEMD.USE.CICSPlus CLASS(FACILITY) ID(ADMGRP) ACCESS(READ)
The following RACF commands permit users ADM1 and ADM2 to maintain the common list of source files in the Common Data Store and to see the expiry days warning for all users' observations on SYSTEMD and SYSTEMP:
PERMIT SYSTEMD.ADMINISTERPRODUCT CLASS(FACILITY) ID(ADMGRP) ACCESS(READ)
PERMIT SYSTEMP.ADMINISTERPRODUCT CLASS(FACILITY) ID(ADMGRP) ACCESS(READ)
Some basic RACF® profiles and explanations are shown here:
Any user can measure jobs with any jobname when the servicing system is SYSTEMD.
Any user is allowed to measure a started task when the servicing system is SYSTEMD.
Any user is allowed to turn on the DB2+ data extractor when the servicing system is SYSTEMD.
Any user is allowed to turn on the IMS+ data extractor when the servicing system is SYSTEMD.
Any user is allowed to measure a specific DB2 stored procedure or user-defined function and/or to turn on the collateral (CDB2) data extractor when the servicing system is SYSTEMD.
Any user is allowed to turn on the CICS+ data extractor when the servicing system is SYSTEMD.
When Application Performance Analyzer operates as a member of a sysplex group, it must use the same security method (Internal, External, or External(Compat)) as the other members of the group. The first Application Performance Analyzer member to initialize sets the security method, all other Application Performance Analyzer members that start must use the same method or they will fail. In addition, it is highly recommended that the External security method be used by all members. Internal and External(Compat) will not produce desired results and are only supported for backward compatibility.
For more information about external security, see Appendix C. Sysplex External Security Conversion Aid.
When using the SecurityHLQ parameter, the SecurityClassName parameter must also be specified. For example, using the parameters:
The VIEW rules for the parameters above would be written as:
RDEFINE CACLASS1 CAZ.SYSTEMD.VIEW.* UACC(NONE)
PERMIT CAZ.SYSTEMD.VIEW.* CLASS(CACLASS1) ID(ADMGRP) ACCESS(READ)
To allow VIEW access on all systems in the sysplex, the rule could be written as:
PERMIT CAZ.*.VIEW.* CLASS(CACLASS1) ID(ADMGRP) ACCESS(READ)
The SecurityHLQ allows the rules to be written for all members of the sysplex rather than having to code a rule for each member.
For more information about external security, see Appendix C. Sysplex External Security Conversion Aid.
[ Top of Page | Previous Page | Next Page | Contents | Index ]