Security of ISPW
This section describes how ISPW can be secured. ISPW uses standard SAF facilities to secure the functions in ISPW. Functions in ISPW are secured by the use of Objects and Methods. Security Rules can be defined at the Object/Method level to secure these functions. It is possible to install ISPW with no security at first, and then add rules to define security checking later.
How does it work?
Input cards to the ISPW CM started task determine how ISPW is to make SAF checks and for which Objects/Methods these checks are to be made. ISPW will dynamically build the SAF Resource Name to check based upon the rules specified to ISPW. Security profiles/rules need to be defined to the local security product in line with the Security Rules specified to ISPW. Security-Objects-and-Methods contains the complete list of Objects/Methods and the attributes that can be used in the security checking.
ISPW Security
“Statement of Integrity”
ISPW’s use of APF authorized code is only for the functionality of ISPW, as described in the product documentation. ISPW has been rigorously tested for security exposures, and any security exposures that come to light in the future will be given Compuware’s highest priority.
Preparing for Security
Defining a SAF Class for ISPW
ISPW makes security checks to SAF which require a Class Name (Generic). It is recommended that a separate SAF Class be defined specifically for ISPW because the ISPW CM started task issues (RACROUTE REQUEST=LIST) against the class at start-up to pre-load all of the profiles. Keeping the ISPW profiles separate provides the maximum level of optimization under SAF.
SAF Class Attributes
The following are some suggested attributes used for the SAF Class definition. The RACF definition is shown as an example:
ID=128,
MAXLNTH=80,
FIRST=ALPHANUM,
OTHER=ANY,
POSIT=25,
OPER=NO
Dynamic RACF CDT Class Definition
Customers that are running z/OS 1.5 or later are now able to dynamically define the SAF Class. An example definition for RACF is shown in the following figure.
Dynamic RACF CDT Class Definition
This can be refreshed using the RACF command:
Defining Security
Server Definition
Input cards are placed in the dataset allocated to the REFRDATA DDName specified for the CM started task. Input cards for security are required for:
- Specification of the SAF Class which ISPW checks for authorities
- Specification of an optional prefix used when building the resource string
- Specification of the Security Rules to define how ISPW functions are to be secured.
Define RACF Class
The format of the input card for the definition of the SAF Class is:
SECCLASS=xxxxxxxx
where xxxxxxxx is the name of the Class.
If a class is specified which does not exist—or no class is specified at all—ISPW will write a message in the log to indicate that it could not load the profiles and internal ISPW security is unavailable.
Define Resource Name Prefix
The format of the input card for the definition of the SAF Class is:
SECPREFIX=xxxxxxxx
where xxxxxxxx is the text of the prefix. This card is optional and should rarely need to be specified if the ISPW Server variable is used in the definition of the Security Rules.
Define Delimiter for Resource Name Variables
The ISPW parameter SECDELIM is used to specify the delimiter for variables in the name. The default is that no delimiter is required, causing recognized variable names to be substituted. For example, a resource name in the Security Rules of SERVER.RL.APPL.METHOD will have SERVER, APPL, and METHOD substituted with the runtime values. This can make it difficult to discern what was a literal and what would be substituted, occasionally leading to unexpected results. So using the parameter SECDELIM=$ makes the variables in the resource name more obvious, as you would use $SERVER.RL.$APPL.$METHOD.
Define Security Rules
Input cards can be defined for each ISPW Object and Method using the following format:
This is described further in the following table.
Define Security Rules
Parameter | Description |
|---|---|
Object | An ISPW defined Object (for example, RELEASE). The wildcard symbol “*” can be used to specify all Objects, but only if “*” has also been used for the Method. See Security-Objects-and-Methods for a complete list of Objects. |
Method | An ISPW defined Method that is valid for a specific Object. (For example, the Method ADD is valid for Object RELEASE.) The wildcard symbol “*” can be used to specify all Methods. The wildcard value for the Method can be specified for both a specific Object and for an Object of “*”. See Security-Objects-and-Methods for a complete list of Methods. |
ResourceName | The value here determines what resource string ISPW builds to pass to the security product for the authorization check. For each Object there are a specified number of variables which can be used in the definition of this string (for example, SERVER, APPL, LEVEL, etc.). These variables are resolved at security check time to build the actual Resource Name to check against. See Security-Objects-and-Methods for a complete list of available variables. |
Access | The SAF authority to be checked for. (For example, does the user have READ authority on the Resource Name.) See Security-Objects-and-Methods for a complete list of available Access levels. |
Default Security
ISPW comes pre-defined with internal rules to determine which security checks are to be made. This default security is described in Security-Objects-and-Methods against each Object and Method. The user-defined Security Rules override these defaults.
Previewing Security Rules
There is an ISPW-supplied program which takes as input the defined Security Rules and produces a report detailing all the ISPW Objects and Methods with the Resource Name string ISPW will check against and the authority required. This is a useful report to validate the rules with the definitions in the security product. The JCL for running this report is shown in the following figure. This JCL can be found in the ISPW SAMPLIB dataset member WZZACDMP.
Previewing Security Rules
Report Layout
See Security-Objects-and-Methods for examples of this report.
The report has three sections:
- Heading
- Input Cards
- Altered Rules.
Heading
AS UPDATED:
Input Cards
The input cards that were input into program are re-printed.
SECCLASS=$ISPW SECPREFIX= SECRULE=’* * DUMMY
NONE’
Altered Rules
The security rules are printed out in the format shown in the following section.
Altered Rules
The security rules for the Objects and Methods are printed out in the format listed in the following table.
AlteredRules
Column | Field | Description |
|---|---|---|
1 | Modify Indicator | This indicates whether the input cards have altered the default rules defined in ISPW. An “M” identifies it as modified. |
3 | Object | The ISPW Object. |
12 | Method | The ISPW Method for the Object. |
21 | Access | The access level that is required for the Object/Method combination. |
30 | Resource String | The SAF Resource String which is checked against to see if the user has the required access. |