CA ACF2 for z/os. IMS Support Guide. r15. Third Edition

Transcription

1 CA ACF2 for z/os IMS Support Guide r15 Third Edition

2 This Documentation, which includes embedded help systems and electronically distributed materials (hereinafter referred to as the Documentation ), is for your informational purposes only and is subject to change or withdrawal by CA at any time. This Documentation is proprietary information of CA and may not be copied, transferred, reproduced, disclosed, modified or duplicated, in whole or in part, without the prior written consent of CA. If you are a licensed user of the software product(s) addressed in the Documentation, you may print or otherwise make available a reasonable number of copies of the Documentation for internal use by you and your employees in connection with that software, provided that all CA copyright notices and legends are affixed to each reproduced copy. The right to print or otherwise make available copies of the Documentation is limited to the period during which the applicable license for such software remains in full force and effect. Should the license terminate for any reason, it is your responsibility to certify in writing to CA that all copies and partial copies of the Documentation have been returned to CA or destroyed. TO THE EXTENT PERMITTED BY APPLICABLE LAW, CA PROVIDES THIS DOCUMENTATION AS IS WITHOUT WARRANTY OF ANY KIND, INCLUDING WITHOUT LIMITATION, ANY IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, OR NONINFRINGEMENT. IN NO EVENT WILL CA BE LIABLE TO YOU OR ANY THIRD PARTY FOR ANY LOSS OR DAMAGE, DIRECT OR INDIRECT, FROM THE USE OF THIS DOCUMENTATION, INCLUDING WITHOUT LIMITATION, LOST PROFITS, LOST INVESTMENT, BUSINESS INTERRUPTION, GOODWILL, OR LOST DATA, EVEN IF CA IS EXPRESSLY ADVISED IN ADVANCE OF THE POSSIBILITY OF SUCH LOSS OR DAMAGE. The use of any software product referenced in the Documentation is governed by the applicable license agreement and such license agreement is not modified in any way by the terms of this notice. The manufacturer of this Documentation is CA. Provided with Restricted Rights. Use, duplication or disclosure by the United States Government is subject to the restrictions set forth in FAR Sections , , and (c)(1) - (2) and DFARS Section (b)(3), as applicable, or their successors. Copyright 2013 CA. All rights reserved. All trademarks, trade names, service marks, and logos referenced herein belong to their respective companies.

3 Contact CA Technologies Contact CA Support For your convenience, CA Technologies provides one site where you can access the information that you need for your Home Office, Small Business, and Enterprise CA Technologies products. At you can access the following resources: Online and telephone contact information for technical assistance and customer services Information about user communities and forums Product and documentation downloads CA Support policies and guidelines Other helpful resources appropriate for your product Providing Feedback About Product Documentation If you have comments or questions about CA Technologies product documentation, you can send a message to techpubs@ca.com. To provide feedback about CA Technologies product documentation, complete our short customer survey which is available on the CA Support website at

4 Documentation Changes The following documentation updates have been made since the last release of this documentation: Update IMS System Definition Removed text associated with the SECURITY macro. Changed all references CTBXPOOL field in the Storage record to IPBXPOOL. Security in IMS DBCTL (see page 323) Added new appendix.

5 Contents Chapter 1: IMS Interface Philosophy 17 Documentation Set Command Notation Design Concepts and Features CA ACF2 and the IMS Interface Validation Processing Protected IMS Resources Network Security IMS Security Options Chapter 2: Planning Considerations 27 Design Concepts and Features Default Logonid Region Logonids Reports User Logonids Planning Checklist Chapter 3: IMS Records 33 Design Concepts and Features ACF Subcommand IMS Record Key Creating and Modifying IMS Records EXITS Record-The IMS Interface Exit Specifications Field Descriptions Network Record - Network Security Specifications Field Descriptions OPTS Record-The IMS Interface Option Specifications Field Descriptions RESOURCE Record-Resource Validation Processing Field Descriptions SIGNON Record-Sign-on Field Descriptions Storage Record-Storage Options Field Descriptions SYSPLEX Record-IMS interface SYSPLEX feature Field Descriptions Contents 5

6 WTO Record-Write to Operator Messages Field Descriptions Chapter 4: Defining Logonids 51 Design Concepts and Features Region Logonids User Logonids Automatic Terminal Signon Logonids Default Logonids Logonid Records Chapter 5: System Control Options 69 Design Concepts and Features Control Region Access Authority Control Region Default Logonid Idle Time Reverification Logonid Suspension Multiple Sign-on Control New Password Verification Security Mode Sign-on Format Sign-on Message Delivery Successful Sign-on Format Terminal Messages Write To Operator Messages Interface Control Options Control Region Access Authority (AUTH) Control Region Default Logonid (DFTLID) Idle Time Reverification (IDLE) ISRT Transaction Validation (ISRTNVAL) Logonid Suspension (SUSPEND) Maximum Security Violations (MAXVIO) Message Driven BMP Validation (BMPMSG) MTO Default Logonid (MTOUSID) Multiple Sign-on Control (ENQNAME) New Password Verification (NPVERIFY) Non-Message Driven BMP Userid (BMPUSID) Password Reverification Limits (PWMAXVIO) Security Mode (MODE) Sign-on Format (FORMAT) IMS Support Guide

7 Sign-on Message Delivery (NOTIFY) Successful Sign-on Format (PSFORMAT) Terminal Messages (MSGBASE) Transaction Classification (FMTPTRAN) Unknown Logonid Processing (NLIDDFLT) Write To Operator Messages Chapter 6: Transaction Security 87 Design Concepts and Features IMS Transactions Implementing Transaction Validation Step 1: Validating Transactions Step 2: Protecting Transactional Sequences Step 3: Defining IMS RESOURCE Records Step 4: Writing Transaction Resource Rules Chapter 7: AGN and RAS Resource Security 99 Design Concepts and Features IMS and IMS Interface AGN Processing Defining Application Group Names to SMU Defining an IMS RESOURCE Record for AGN Validation Writing Application Group Name Resource Rules RAS Security Defining an IMS RESOURCE Record for RAS Transaction Validation Writing Resource Rules for RAS Transaction Security Defining an IMS RESOURCE Record for RAS PSB Validation Writing Resource Rules for RAS PSB Security Defining an IMS RESOURCE Record for RAS LTERM Validation Writing Resource Rules for RAS LTERM Security Chapter 8: IMS Command Security 107 Design Concepts and Features Default IMS Security Security Maintenance Utility (SMU) IMS Interface Validation of Terminal Commands IMS Interface Validation of Type 1 AOI Commands IMS Interface Validation of Type 2 AOI Commands AOI Commands in an IMS Shared Queues Environment Implementing Command Validation Step 1: Validating Commands Contents 7

8 Step 2: Defining IMS RESOURCE Records for Command Validation Step 3: Writing Command Resource Rules Exit Processing and IMS Command Keyword Security Chapter 9: PSB Security 119 Design Concepts and Features Defining IMS RESOURCE Records Writing PSB Resource Rules Chapter 10: MSC and ISC Link Security 123 Design Concepts and Features ISC Concepts MSC Concepts Default IMS Interface Security for MSC and ISC Links Default IMS Interface Security for ISC Links Default IMS Interface Security for MSC Links Extended IMS Interface Security for MSC and ISC Links IMS NETWORK Records Chapter 11: LOCK and UNLOCK Command Resource Security 133 Design Concepts and Features Transactions on the LOCK and UNLOCK commands Defining the IMS RESOURCE Record Writing the Resource Rules Programs on the LOCK and UNLOCK commands Defining the IMS RESOURCE Record Writing the Resource Rules Databases on the LOCK and UNLOCK commands Defining the IMS RESOURCE Record Writing the Resource Rules LTERMs on the LOCK and UNLOCK commands Defining the IMS RESOURCE Record Writing the Resource Rules Chapter 12: APPC Security 141 Design Concepts and Features APPC Processing System Authorization Facility (SAF) Program-to-Program (PTP) Message Switching IMS Support Guide

9 Security processing during APPC session establishment IMS Interface Network Security for APPC IMS NETWORK Records SAF Security for APPC/IMS Requesting APPC/IMS SAF security Implementing APPC/IMS SAF Security Choosing Your APPC Security Implementation Using IMS Interface NETWORK Security without APPC/IMS SAF Using APPC/IMS SAF and IMS Interface NETWORK Security Using APPC/IMS SAF without the IMS Interface NETWORK Security Not Using APPC/IMS SAF or the IMS Interface NETWORK Security DFSAPPC Chapter 13: OTMA Security 153 Design Concepts and Features OTMA Processing System Authorization Facility (SAF) Program-to-Program (PTP) Message Switching IMS Interface Network Security for OTMA IMS NETWORK Records SAF Security for IMS OTMA Requesting SAF security for IMS OTMA Implementing IMS OTMA SAF Security Choosing Your OTMA Security Implementation Using IMS Interface NETWORK Security without IMS OTMA SAF Using IMS OTMA SAF and the IMS Interface NETWORK Security Using IMS OTMA SAF without the IMS Interface NETWORK Security Not Using IMS OTMA SAF or the IMS Interface NETWORK Security TPIPE Security for the RESUME TPIPE Request Chapter 14: IMS Shared Queues and Security 167 Overview Design Concepts Shared Queues Front-end Region Back-end Region Program-to-Program Message Switching Automated Operator Interface Commands AUTH Calls Default Processing Contents 9

10 Design Features CA ACF2 IMS SYSPLEX Feature SYSPLEX Feature Processing CA ACF2 IMS Shared Queues NETWORK Record Choose Your Security Process Chapter 15: ACF Transaction 183 ACF Transaction END Request SET Request Parameters INSERT Request Parameters CHANGE Request Parameters DELETE Request Parameters LIST Request Chapter 16: ACF Command 189 Design Concepts and Features RELOAD Function Syntax Parameters Processing Response RESET CACHE Function Syntax Parameters Processing Response RESET LINK Function Syntax Parameters Processing Response SHOW LINK Function Syntax Parameters Processing IMS Support Guide

11 Response SHOW SIGNON Function Syntax Parameters Processing Response SHOW STATE Function Syntax Parameters Processing Response SHOW STORAGE Function Syntax Parameters Processing Response SHOW SYSPLEX Function Syntax Parameters Processing Response SYSPLEX CLEAR Function Syntax Parameters Processing Response SYSPLEX START Function Syntax Parameters Processing Response SYSPLEX STOP Function Syntax Parameters Processing Response The ACF Command in an IMSplex Chapter 17: Reports 205 Design Concepts and Features Report Generators Contents 11

12 ACFRPTEL-The Infostorage Update Log ACFRPTPW-The Invalid Access/Authority Log ACFRPTRV-The Generalized Resource Event Log ACFRPTRX-The Logonid Access Report ACFRPTXR-The Cross-Reference Report ACFRGP-The Resource Grouping Utility Chapter 18: Additional Considerations 209 Design Concepts and Features The /ACF Command The AUTH Call Idle Time Resource Rule Directories The VERIFY Keyword The Greeting Message Exit Using Password Reverification Idle Time Considerations VERIFY Considerations Using Rule Directories Loading and Reloading Globally Resident Directories Loading and Reloading Locally Resident Directories Maintaining IMS Records Signing On With The IMS Interface Requiring Terminals to Sign On Signing On With an MFS Format Verifying a New Password Changing Sign-on Messages Automatic Terminal Signon Understanding Security Implications of the ACF Transaction Supporting Transactions that Submit Jobs Supporting the AUTH Call with the IMS Interface AUTH Call Issuing the AUTH Call IMS Interface Processing of the AUTH Call Information Returned to the Application Program Chapter 19: Storage 225 Design Concepts and Features Pool Processing Types of Storage Area Pools IMS Support Guide

13 Storage Utilization CA ACF2 Storage Requirements IMS Interface Storage Requirements The Storage Record Tuning the IMS Interface Storage Allocations CACHENT# Option IMS Interface Storage Pools Chapter 20: Installation Procedure 237 Pre-Installation Requirements Packaging Considerations Design Concepts and Features Overview of the Installation Procedure ACFFDR Values Relevant to the IMS Interface How You Acquire the Product Installation Checklist Prepare the z/os System for the CA ACF2 IMS Installation Complete the CA ACF2 Requirements Install the IMS Interface in an IMS Control Region Detailed Installation Instructions Make IMS Interface APF-Authorized Create or Update the IMS Interface APPLDEF Records Customize ACFFDR Create or Update IMS User Messages Table Define ACF Command Update IMS System Definition Run IMS System Definition Modify IMS Command Table Provide CA ACF2 Logonid Maintenance Provide MFS Format Modify the IMS OM Command Table Create/Modify IMS Interface Options, Logonids, Rules Initialize IMS Interface Chapter 21: User Exits 251 Design Concepts and Features Exit Procedures and Considerations Defining the IMS Exits Record Initialization Exit (INITIAL) Exit Control Area DSECT Contents 13

14 Exit Control Area Fields that Can Be Supplied or Changed Presign-on Exit (PRESIGN) Exit Control Area DSECT Descriptions of Some Exit Control Area Fields Exit Control Area Fields that Can Be Supplied or Changed Sign-on Exit (SIGNON) Exit Control Area DSECT Descriptions of Some Exit Control Area Fields Exit Control Area Fields that Can Be Supplied or Changed Sign-off Exit (SIGNOFF) Exit Control Area DSECT Descriptions of Some Exit Control Area Fields Exit Control Area Fields that Can Be Supplied or Changed Prevalidation Exit (PREVAL) Exit Control Area DSECT Descriptions of Some Exit Control Area Fields Exit Control Area Fields that Can Be Supplied or Changed Postvalidation Exit (POSTVAL) Exit Control Area DSECT Descriptions of Some Exit Control Area Fields Exit Control Area Fields that Can Be Supplied or Changed Idle Time Exit (IDLE) Exit Control Area DSECT Exit Control Area Fields that Can Be Supplied or Changed Chapter 22: Migration 275 Migrating from Prior Releases of the CA ACF2 IMS Interface to r9 or Above Migrating from Prior Releases of the CA ACF2 for z/os to r Appendix A: SMU Conversion 279 Converting Type 1 AOI Command Security to CA ACF SMU Security for Type 1 AOI Commands CA ACF2 Security for Type 1 AOI Commands Implementation Steps for AOI=TRAN Security The ACFDCSM1 Utility Executing the ACFNRULE Statements Implementation Steps for AOI-YES Security The ACFDCSM3 Utility Converting AGN Security to RAS Application Group Names IMS Support Guide

15 Resource Access Security Converting Terminal Based Security to CA ACF SMU Terminal-Based Security for Transactions and Commands CA ACF2 Security Transactions and Commands Converting SMU Terminal-Based Security to CA ACF SMU Functionality Without CA ACF2 Equivalent SMU Signon Requirements Password for IMS Resources ACFDCSM5 Utility Appendix B: Security in IMS DBCTL 323 Overview Design Concepts CSL OM Environment IMS Commands IMS DBCTL Region MCS and EMCS Consoles Program Specification Block System Authorization Facility (SAF) Resource Security in DBCTL Program Specification Block Commands CA ACF2 IMS Security for DBCTL Resources Program Specification Block Commands from MCS/EMCS Consoles Commands from Application Programs Commands from the SCL OM Environment Implementing CA ACF2 IMS Security for DBCTL IMS Control Records for DBCTL Implementing CA ACF2 IMS Security for DBCTL The /ACF Command in DBCTL SAF Security for DBCTL Resources Program Specific Block Commands from MCS/EMCS Consoles Commands from Application Programs Commands from the SCL OM Environment Contents 15

16

17 Chapter 1: IMS Interface Philosophy The IMS Support Guide is both a tutorial and a reference guide for IMS users who install and implement the CA ACF2 IMS interface (IMS interface) in an IMS control region. The intended audience for this guide consists of security administrators, database administrators, and systems programmers. A working knowledge of the IMS TM (Transaction Manager) environment and of the CA ACF2 for z/os (CA ACF2) host product is required to understand this guide. This section contains the following topics: Documentation Set (see page 17) Documentation Set In addition to this guide, there are several other guides that comprise the CA ACF2 documentation set. For a complete list of the CA ACF2 documentation set and related documentation, see the Administrator Guide. The following publications are not produced by Computer Associates, but might be used for reference and are recommended reading: IMS Command Reference IMS Application Programming: Transaction Manager MVS Routing and Descriptor Codes Command Notation This guide uses the following command notation. Enter the following exactly as they appear in command descriptions: UPPERCASE Identifies commands, keywords, and keyword values that must be coded exactly as shown. MIXed Cases Identifies command abbreviations. The uppercase letters are the minimum abbreviation; lower case letters are optional. Symbols All symbols (such as equal signs) must be coded exactly as shown. Chapter 1: IMS Interface Philosophy 17

18 Documentation Set The following clarify command syntax; do not type these as they appear: lowercase Indicates that you must supply a substitution (a user-supplied value). [ ] { } Identifies optional keywords or parameters. Requires choosing one of the keywords or parameters listed. Underlining Shows default values that need not be specified.... Separates alternative keywords and parameters, choose one Preceding items or group of items can be repeated more than once. Sample Command DEComp {* ruleid Like(ruleidmask)} [Into(dsname)] Explanation: DEC Command abbreviation. * Required alternative keyword. ruleid Required alternative keyword. Like(ruleidmask) Required alternative keyword. Into(dsname) Optional parameter. This chapter provides a general description of the IMS security interface for the IMS TM (Transaction Manager) environment. Major IMS interface design concepts and features are introduced. A fundamental description of the IMS interface validation processing is provided, and the interaction of the IMS interface and CA ACF2 is described. A brief summary of IMS security options is also provided. This summary includes general information about other CA ACF2 and IMS interface products available to IMS users. 18 IMS Support Guide

19 Documentation Set Design Concepts and Features CA ACF2 IMS TM Interface The IMS TM (Transaction Manager) interface provides maximum security for IMS online resources and provides CA ACF2 product consistency. The following security concepts and features constitute the basis of the IMS TM Interface. There are several CA ACF2 security products. To install and implement the IMS TM Interface, CA ACF2 must also be installed. Unlike other security software products on the market, CA ACF2 protects data by default, meaning as soon as you install it in your system, data is automatically secured. After you install, you can discriminately grant access to data. In keeping with this CA ACF2 security philosophy, the IMS interface also provides protection by default. CA ACF2 and the IMS interface interact to provide maximum security. CA ACF2 provides data set security while the IMS interface protects resources such as IMS transactions. This interface protects IMS resources in the IMS TM (Transaction Manager) environment. Global System Options (GSO) Records IMS Records GSO records define CA ACF2 security options. Although you use GSO records to implement CA ACF2, you do not use them to implement the IMS interface. IMS records implement the IMS interface. IMS records have options similar to the GSO records, but they are tailored to the needs of IMS interface users. IMS records define the type and level of security that the IMS interface provides. They define the specific action the IMS interface takes in the event of an attempted access or use of an IMS resource. There are several types of IMS records: IMS OPTS Implements the IMS interface control functions. These control functions determine how the IMS interface processes validations for the entire IMS TM environment. IMS WTO Defines control options for write to operator (WTO) messages for the IMS interface. IMS EXITS Defines user exits for the IMS interface. Chapter 1: IMS Interface Philosophy 19

20 Documentation Set IMS SIGNON Specifies how the IMS interface validates sign-ons. IMS RESOURCE Defines the IMS resources that are protected by the IMS interface. Each type of resource has its own RESOURCE record. For example, IMS transaction validations are controlled by a transaction RESOURCE record. IMS NETWORK Defines options that control how the IMS interface provides security for network connections in an IMS system. These network connections include ISC and MSC links, and APPC and OTMA connections. A NETWORK record is also supported for the IMS Shared Queues (SQ) environment. IMS STORAGE Defines options that control the IMS interface use of storage. IMS SYSPLEX Control the IMS interface SYSPLEX feature, which uses a coupling facility structure in an IMS shared queues environment. IMS records are stored in the Infostorage database and retrieved from the database when the corresponding IMS region is initiated. Network Security The IMS interface protects IMS resources in IMS control regions that receive transactions from other control regions and systems in the network. Resource Rules The IMS interface uses standard CA ACF2 resource rules to secure IMS resources. A resource rule defines who or what can access a particular resource. It contains the following components: The name of the resource to be secured by the rule What the identified users can do with the resource named The conditions under which access is permitted (See the Administrator Guide for more information about resource rules. The glossary in this guide includes a definition of the UID.) 20 IMS Support Guide

21 Documentation Set Security Inheritance User Exits Validation Caching The IMS interface security functions for IMS online processing are built on a design foundation called security inheritance. The inherited element is the user's CA ACF2 logonid. Specifically, security inheritance is the method of associating a user with a transaction and all the transactions that it invokes. For example, when Jane Doe enters an IMS transaction code at her terminal, IMS interface uses her CA ACF2 logonid to determine whether to permit IMS to execute the transaction for Jane Doe. The correspondence between Jane Doe's logonid and the transaction remains intact until the transaction and all the transactions that it invokes are completely processed. Security inheritance ensures that IMS users execute only those transactions assigned to them in the CA ACF2 resource rules. The benefits of security inheritance are described in more detail in the IMS Security Options section. The IMS interface lets you use exits that interact with the interface to perform security functions of your own design. You can program these exits to override the IMS interface validations with a different type of validation. You can also program them to provide additional validations. Validation caching is a major performance feature of the IMS interface. It is the process of recording allowed accesses to resources and keeping this information in storage (a cache) for quick reference. After an access authority is recorded in the cache, the IMS interface can refer to the cache each time additional access attempts are made that are based on the recorded access authority. Use of the cache for validation references saves the IMS interface processing time. Without validation caching, it would need to perform a resource rule interpretation each time it processed a validation, which would be far more time consuming than referring to the more readily available cache. CA ACF2 and the IMS Interface Validation Processing Data Set Access Validations The IMS TM Interface interacts with CA ACF2 to secure IMS TM environments. Data set access validations are performed by CA ACF2. CA ACF2 and the IMS interface work in conjunction to perform system entry and resource access validations. Data set access validations are performed entirely by CA ACF2. When a user attempts access to a data set, CA ACF2 determines whether to permit or deny the requested access by consulting the Rules database. Chapter 1: IMS Interface Philosophy 21

22 Documentation Set System Entry Validations Resource Access Validations The method of validating data set accesses depends upon the CA ACF2 security mode. When CA ACF2 is in ABORT mode (the default mode), unauthorized access attempts are denied. When CA ACF2 is in WARN mode, all data set access attempts are permitted; however, the z/os console operator might be warned when an unauthorized access is made, and the unauthorized access is logged. When CA ACF2 is in LOG mode, all data set access attempts are permitted, but all unauthorized accesses are logged and can be easily traced by a security administrator. When CA ACF2 is in QUIET mode, data set access attempts are not validated. When system access is attempted (that is, sign-on), the IMS interface gathers pertinent user information such as the logonid, password, terminal ID, and, if specified, the group name, and it passes the information to CA ACF2. CA ACF2 checks the Logonid database to determine whether the user can perform the sign-on function. A user is authorized to sign on if CA ACF2 finds the user's logonid record, a matching password, and matching source and shift conditions. In addition, if a group name was specified at sign-on, CA ACF2 verifies that the user has the authority to use that group's access privileges. If all of the user information satisfies the requirements for system access, CA ACF2 passes to the IMS interface a recommendation to let the user access the system. The IMS interface then determines whether the user is authorized to access the particular IMS control region. If all CA ACF2 and IMS interface system entry requirements are met, the IMS interface permits the IMS system to process the sign-on request. If any of the requirements are not met, the sign-on request is terminated. When the IMS interface validates a resource access request (for example, an attempt to issue an IMS transaction), it passes the associated logonid, source, resource type code, and resource name to CA ACF2. CA ACF2 compares this information to the resource rule and to the source and shift conditions defined in the Infostorage database. If the information satisfies the access requirements, CA ACF2 recommends to the IMS interface that access be permitted. If the user information does not satisfy the access requirements, CA ACF2 recommends to the IMS interface that access to the resource be denied. The method of validating resource accesses depends upon the IMS security mode. If the IMS interface is in ABORT mode, it acts in accordance with the CA ACF2 recommendation. If it is in LOG mode, access to the resource is permitted, regardless of the CA ACF2 recommendation; however, all unauthorized accesses are recorded. When the subsystem is in QUIET mode, resource access attempts are not validated. The IMS TM Interface does not support WARN mode. 22 IMS Support Guide

23 Documentation Set Validation Caches and Exits Validation caches and user exits can alter the resource validation processing previously described. For IMS terminal users who are signed on, the IMS interface builds a validation cache when the user signs on. Whenever the user is granted access to a protected resource, the IMS interface records this fact in the cache and refers to the cache whenever these access requests are repeated during the same session. Referring to the cache for resource validations enables the IMS interface to bypass the CA ACF2 validation processing and eliminate some processing overhead. When the user signs off, the cache is erased. The next time this user signs on, the process begins again; the initial resource access requests are validated through CA ACF2 normal processing, and a new cache is built for the authorized accesses of the new session. If a successful access request comes from a terminal that is not signed on, the IMS interface creates and maintains a cache for the default logonid for that terminal. Cache and validation processing takes place as previously described. This cache, however, is scanned periodically. When the IMS interface determines that the terminal is no longer active, the associated cache is erased. User exit programs can be used to tailor validation processing to a site's unique security needs. The exit programs can change or override the CA ACF2 and the IMS interface resource validations. For more information about these exits, see the chapter Installation Procedures. Protected IMS Resources Transaction Security AGN Security The IMS TM Interface protects the following IMS resources. The IMS interface validates IMS transactions before they reach the message queue in the IMS control region. In general, transactions are validated when they are initiated directly from a terminal or indirectly from a BMP or another transaction. The IMS interface validates transactions by matching UIDs and access conditions with transaction resource rules. To ensure that a correct match of a UID to a resource rule is made, the IMS interface provides security inheritance. (See Design Concepts and Features earlier in this chapter for a description of security inheritance.) The IMS interface protects AGNs that are accessed by IMS dependent regions such as BMPs. AGN security lets you control the transactions, terminals, and PSBs a dependent region is permitted to access. Validation processing for AGNs is performed by matching the dependent region's UID and access conditions to AGN resource rules. Chapter 1: IMS Interface Philosophy 23

24 Documentation Set RAS Security for Transactions, PSBs, and LTERMs PSB Security Command Security In IMS release 9.1 and above, Resource Access Security (RAS) is available as a replacement for AGN security. If RAS security is enabled, AGN security cannot be used. The IMS interface performs security validations for the transactions, PSBs, and LTERMs that are accessed by IMS dependent regions. Validation processing for these resources is performed by matching the dependent region's UID and access conditions to the appropriate resource rules. The IMS interface protects PSBs that are used by BMPs. Validation processing for these PSBs is performed by matching the BMP region's UID and access conditions to PSB resource rules. The IMS interface protects IMS commands issued directly by a terminal user or indirectly by application programs using the ICMD communications call. For IMS release 9.1 and above, the IMS interface also protects IMS commands issued by applications programs using the CMD communications call. Validation processing for commands is performed by matching the user's UID and access conditions to command resource rules. Resources on the LOCK and UNLOCK Commands OTMA Transaction Pipes (TPIPEs) For IMS release 9.1 and above, the IMS interface performs security validations for transactions, programs, LTERMs, and databases that are specified on the IMS LOCK and UNLOCK commands. Validation processing for these resources is performed by matching the user's UID and access conditions to the appropriate resource rules. For IMS Version 10 and above, the IMS interface performs security validations for OTMA transaction pipes (TPIPEs) that are specified by an OTMA client on a RESUME TPIPE request. Validation processing for these resources is performed by matching the RETUME TPIPE requestor's UID and access conditions to the appropriate resource rules 24 IMS Support Guide

25 Documentation Set Network Security The IMS TM Interface secures IMS resources that can be accessed through a network communications link to the IMS region. The IMS interface validates all attempts to access a resource in an IMS control region at the receiving end of a link. These network validations are performed in one of three ways: Matching the UIDs of user logonids inherited from the sending IMS control region to resource rules Matching the UIDs of link default logonids and their access conditions to resource rules Matching the UID of the IMS control region default logonid to resource rules IMS Security Options IMS Security Functions The following options are available in providing security in the IMS environment: IMS security functions The IMS Batch Interface The IMS TM Interface IMS provides SMU and PSBs to protect commands, transactions, and databases. SMU (Security Maintenance Utility) protects commands and transactions, but it does not provide individual accountability among users because commands and transactions are validated against terminal IDs rather than user logonids. Particular terminals are permitted or denied the ability to execute a command or transaction, and all users working from the same terminal have the same privileges. To attain different privileges, the user can use another terminal that has the other privileges assigned to it. Another security problem IMS users encounter with SMU is the inability to protect secondary transactions. Terminals that are permitted to execute primary transactions are also permitted (indirectly) to execute associated secondary transactions. PSB security consists of permitting application programs access to particular database segments. To access a database segment, an application program requires a PSB that defines the database segments it is permitted to access. In batch and BMP environments, the most serious security problem with the PSB security is the user's ability to use any PSB with any application program. Therefore, security control provided by the PSB can be easily bypassed. Chapter 1: IMS Interface Philosophy 25

26 . Documentation Set IMS Batch Interface The IMS Batch Interface was developed specifically for the IMS batch environment. The interface protects database segments and PSBs by associating users with segment and PSB resource rules. The major advantage the IMS Batch Interface has over previous methods of securing IMS resources is that it provides individual accountability among users For more information about the IMS Batch interface, see the IMS Batch Support Guide. IMS TM Interface The IMS TM Interface was developed specifically for the IMS online or TM (Transaction Manager) environment. The IMS TM Interface protects IMS resources in the online environment and provides individual accountability by associating users (UIDs) with resource rules and access conditions. The IMS interface security inheritance enables this individual accountability to remain intact for both primary and secondary transaction validations. 26 IMS Support Guide

27 . Chapter 2: Planning Considerations This chapter gives you an idea of the scope of the decision-making and tasks required to install and implement the IMS TM Interface. You can use the step-by-step plan provided in this chapter as a checklist of things to do to ensure the smooth flow of your installation and implementation efforts This chapter also assists you by prioritizing and timing the tasks. The tasks on the checklist are presented in the order that they should be performed. For example, we recommend that even though you can install the IMS interface before any IMS record options are selected, you should select the options before you install the interface. This section contains the following topics: Design Concepts and Features (see page 27) Planning Checklist (see page 29) Design Concepts and Features The concepts and features included in this chapter reflect the major planning issues you must consider before you install and implement the IMS TM Interface. Default Logonid When no logonid is submitted or inherited with a request, the CA ACF2 IMS interface assigns a default logonid to the request to perform access validations. The IMS interface uses two kinds of default logonid: Control Region Default-Logonid to validate unknown users, that is, users who have submitted transaction requests without signing on, thereby rendering them as unknown to the IMS interface. Network Link Default Logonids-Link default logonid to validate a resource access attempt made from a link in an IMS network when the associated user logonid is not inherited. Chapter 2: Planning Considerations 27

28 Design Concepts and Features Region Logonids CA ACF2 uses region logonids to validate the initiation of IMS regions. Region logonids also validate data set and resource access attempts made by the region. These logonids are as follows: BMP Region Logonids-Determines if the BMP can be initiated. The IMS interface uses the BMP logonid to validate tasks initiated by the BMP, for example, transactions that the BMP places on the message queue. Control Region Logonid-Validates data set access attempts made by the control region. This logonid is also known as a MUSASS logonid. DBRC Region Logonid-Validates initiation of the IMS database recovery region and data set access requests made by the database recovery region. DLISAS Region Logonid-Validates initiation of the DLISAS region. Data set access requests made by the DLISAS region are validated with the DLISAS logonid. Fast Path Region Logonid-If your site is using IMS fast path regions, you must create fast path region logonids. CA ACF2 uses the fast path region logonid to determine whether to permit initiation of the IMS fast path region and to validate data set access attempts made by the fast path region. IMSRDR Region Logonid-Determines whether to permit initiation of the IMS reader and to validate data set access attempts Message Processing Region Logonid-Determines whether to permit initiation of the IMS message-processing region and to validate data set access attempts made by the message-processing region. Reports The IMS Interfaces use the CA ACF2 base product security reports that inform the security administrator of security violations. The reports also provide general status information about logonids, resources, and the Infostorage database. User Logonids You must define logonids for all IMS users. Users enter their logonids when they sign on to IMS. 28 IMS Support Guide

29 Planning Checklist Planning Checklist Administrators and security administrators can use this section to ensure the smooth flow of the IMS interface installation and implementation events. It can also be used to ensure that nothing is overlooked during the installation and implementation of the IMS interface. The items on the following list reflect the tasks you must complete to implement and install a single IMS TM Interface. If you must plan for more than one IMS TM Interface, you can make copies of this checklist so you can use it again. 1. Make sure that your site has the following IMS interface prerequisite software: IMS Release 9.1 or above CA ACF2 r15 or above Any supported release of z/os 2. Modify the CA ACF2 system generation to include macro definitions for the IMS interface. The systems programmer can modify the generation while the security administrator plans for the IMS records. Modify the following @CFDEs 3. Determine the interface control functions for IMS interface processing: The OPTS record The WTO record The SIGNON record The NETWORK records The SYSPLEX record Chapter 2: Planning Considerations 29

30 Planning Checklist 4. Define your site's logonid requirements: Region logonids BMP regions Control region DBRC region DLISAS region Fast path regions IMSRDR region Message processing regions Default logonid Control region ISC links MSC links APPC OTMA User logonids 5. See the IMS RESOURCE records and determine your site's resource security requirements: Transactions Commands PSBs AGNs RAS security for transactions, PSBs, and LTERMs (IMS 9.1 and above) LOCK and UNLOCK resource security for transactions, programs, LTERMs, and databases (IMS 9.1 and above) OTMA TPIPE security for the RESUME TPIPE request (IMS Version 10 and above) 30 IMS Support Guide

31 Planning Checklist 6. Determine the types of exits you need. 7. Install the IMS interface: Ensure that you complete the most crucial IMS record planning before you install the IMS TM Interface. Ensure that you have made all migration decisions. See the IMS STORAGE record and determine the storage requirements for the IMS interface. See the IMS EXITS record, and determine the type of exits you want to use. Then, write whatever exit programs you have determined are necessary. Note: To create exits, the systems programmer and the security administrator must work together and understand the requirements. The exits' module names must be specified on the IMS EXITS record. Follow the procedures in the chapter Installation Procedures to install your site's IMS TM Interface 8. Create your IMS records at the terminal. 9. Set up or adjust CA ACF2 reports. 10. Create logonid records: Region logonids BMP regions Control region DBRC region DLISAS region Fast path regions IMSRDR region Message processing regions Default logonids Control region ISC link MSC link APPC OTMA User logonids Chapter 2: Planning Considerations 31

32 Planning Checklist 11. Create Resource Rules: Transaction Commands PSBs AGNs RAS security for transactions, PSBs, and LTERMs (IMS 9.1 and above) LOCK and UNLOCK resource security for transactions, programs, LTERMs, and databases (IMS 9.1 and above) OTMA TPIPE security for the RESUME TPIPE request (IMS Version 10 and above) 32 IMS Support Guide

33 Chapter 3: IMS Records This chapter provides a basic introduction to the IMS control records. It illustrates the various types of IMS records and describes generic procedural information. Detailed information regarding how to select and use specific options is provided in later chapters that discuss related security functions and features. This section contains the following topics: Design Concepts and Features (see page 33) Creating and Modifying IMS Records (see page 35) EXITS Record-The IMS Interface Exit Specifications (see page 36) Network Record - Network Security Specifications (see page 37) OPTS Record-The IMS Interface Option Specifications (see page 39) RESOURCE Record-Resource Validation Processing (see page 42) SIGNON Record-Sign-on (see page 45) Storage Record-Storage Options (see page 47) SYSPLEX Record-IMS interface SYSPLEX feature (see page 48) WTO Record-Write to Operator Messages (see page 49) Design Concepts and Features The IMS records are designed to provide a large assortment of security controls and features to let security administrators select the type of security most appropriate for your site's needs. This section describes how to use the ACF command facility to define the IMS records to the Infostorage database. ACF Subcommand Use the ACF command and its associated subcommands to create and modify all IMS records. You can issue the ACF command from TSO Ready mode or use the ACFBATCH utility, then enter the ACF subcommand to create an IMS record. For more information about the ACF command and the ACFBATCH utility, see your Administrator Guide. You must establish the ACF subcommand setting with the SET subcommand before you can execute any of the other ACF subcommands. The SET subcommand defines the infostorage record key that identifies the IMS records. After the ACF subcommand setting and the record key are established, you can execute the other ACF subcommands such as INSERT, CHANGE, and LIST. For more information about the ACF subcommands, see your Administrator Guide. Chapter 3: IMS Records 33

34 Design Concepts and Features IMS Record Key The record key for IMS records consists of the following identifiers: Infostorage Class Type A one-character ID that defines the CA ACF2 record class for all IMS records. All IMS records belong to the CONTROL class of CA ACF2 records; therefore, the one-character ID for all IMS records is the letter C. A three-character ID that defines the kind of record in the CA ACF2 record class. The letters IMS are specified for all IMS records. DIVISION(musid jobname) A one- to eight-character value defining the specific control region that uses this record. If you want to have more than one control region use this record, you can use the MDIVISION field instead of the DIVISION field and the standard CA ACF2 masking character, the asterisk (*). If you do not want to use masking, the DIVISION value must match the MUSID field value in the control region's logonid record. If you do not specify the MUSID field value, the DIVISION value must match the job name or the procname specified in the JOB statement in the region's startup JCL. Most security administrators prefer to use the MUSID field value because it is not affected by changes that are made to the startup JCL. If you use the job name or procname as the DIVISION value, any changes made to the JCL might require you to change the DIVISION value so that it matches the JCL. For more information about the DIVISION or MDIVISION field, see the explanations for SYSID and MSYSID in the Administrator Guide. For more information about the MUSID logonid record field, see the chapter Defining Logonids. Record ID An ID that defines the specific security function or feature that the IMS record implements. The following record IDs are available for IMS records: EXITS NETWORK OPTS RESOURCE SIGNON STORAGE SYSPLEX WTO 34 IMS Support Guide

35 Creating and Modifying IMS Records Qualifier A one- to eight-character ID that distinguishes one record from all others defined to the same infostorage class, type, DIVISION field, and record ID. The qualifier field provides a more specific naming convention. For example, a good analogy is the following: when several John Smiths are listed on an attendance list of a class, one way to distinguish them from each other is to add their middle names. Each middle name is the equivalent of a division field of a record key. If after you have added their middle names, you still have identical names, say, three John Joe Smiths, you might want to add a fourth name, such as Jr. or Sr. to distinguish them from each other. This name is the equivalent of the qualifier field of the record key. The qualifier is a mandatory part of the record key whenever you must create more than one of the same type of IMS record. For example, you must enter a qualifier if you are defining more than one IMS RESOURCE record to enable the IMS interface to distinguish one RESOURCE record from another. These IMS records can use qualifiers in their record keys: NETWORK RESOURCE Because each IMS control region can use only one of the following types of IMS records, these IMS records do not use qualifiers in their record keys: OPTS WTO EXITS SIGNON STORAGE SYSPLEX Creating and Modifying IMS Records This section describes how to enter IMS record keys and record options at a terminal. To create or modify an IMS record, enter the following commands from TSO Ready mode at your terminal: ACF SET C(IMS) {INSERT CHANGE} DIVISION(musid jobname) recid[qualifier] -. [option(value)] [ADD REP DEL] Chapter 3: IMS Records 35