Implementing Security for IMS › Transaction Security › Transaction Security Implementation

Transaction Security Implementation

CA Top Secret transaction security is controlled by the SECLVL=TRANAUTH and TYPE=RACFTERM parameters of the IMS system definition SECURITY macro, and by the RCF= and TRN= IMS initialization parameters.

Transactions from Terminals

Transaction validation is performed for transactions entered directly from an IMS terminal.

Note: Transaction validation is also performed during the validation of the IMS operator command:

/SET TRANSACTION transaction

CA Top Secret secures terminal transactions using either OTRAN (resource) security or the Limited Command Facility (LCF).

Transactions from Application Programs

IMS application programs can initiate IMS transactions by performing a program-to-program message switch, that is, the application program issues an ISRT DLI communications call to a non-modifiable TP PCB that specifies a transaction destination, or the application program issues a CHNG DLI communications call to a modifiable TP PCB that specifies a transaction destination, followed by ISRT calls to the new destination.

For program-to-program message switches that use an ISRT DLI communications call to a non-modifiable TP PCB, no CA Top Secret transaction validation is performed.

For program-to-program message switches that use a CHNG DLI communications call to a modifiable TP PCB, a SAF call is performed that provides the CA Top Secret transaction validation in the TIMS resource class. See the SAF Security section in this chapter, for more information on the SAF calls for transaction validation.

Note: When the application program issuing the CHNG call is a BMP, the ACID used for the transaction validation depends on the value of the BMPUSID parameter specified in IMS DFSDCxxx data communications PROCLIB member:

• When BMPUSID=USERID is specified, a signon is performed for the ACID assigned to the BMP job or task and this ACID is used for the transaction validation. If the ACID is not allowed to signon to the control region, CHNG call transaction security is ignored.
• When BMPUSID=PSBNAME is specified, a signon is performed for an ACID with the same name as the PSBNAME specified in the BMP JCL (not the PSBNAME for the transaction being inserted), and this ACID is used for the transaction validation. If the ACID does not exist or if the ACID is not allowed to signon to the control region, CHNG call transaction security is ignored.

Transactions from MSC

Transactions can enter an IMS region from another IMS system over an MSC network link. These transactions can be divided into two types:

• Directed routing transactions might not be defined in the sending IMS system. An application program initiates a directed routing transaction by specifying the transaction code and the ID of the target IMS region to which the transaction should be sent.
• Non-directed routing transactions are defined in the sending IMS system. An application program initiates a non-directed routing transaction by specifying the transaction code. The transaction definition in the sending IMS system includes the ID of the target IMS region to which the transaction should be sent.

For directed routing transactions, no CA Top Secret transaction validation is performed in the receiving IMS system.

For non-directed routing transactions, CA Top Secret allows you to perform a transaction validation and to choose what userid should be used for validation process.

Transaction validation for MSC non-directed routing transactions is determined by the values of the IMSMSC field of the IMS control region ACID of the receiving system.

The format to specify the IMSMSC values is:

TSS ADDTO(acid) IMSMSC('msname1(option),msname2(option)...')

The acid value is the ACID for the IMS control region of the receiving IMS system.

The msname operands identify the MSC links in the receiving IMS system the options are defined for. The values for the msname operands are the labels on the MSNAME statements that define the MSC logical links as defined in the receiving system IMS system definition. Use the linkname ALL for all previously unspecified linknames in the Stage 1 gen for this region to receive the associated link option.

For each MSC link, the option value determines the ACID used for the transaction validations:

acid

Specifies the default ACID for this MSC link. This ACID is signed on during IMS control region initialization and used for the validation of all non-directed routing transactions received on the MSC link. Ensure that the acid specified is not used for session sign on (for example through SOURCE restriction). An ACID used for an IMSMSC link and online session sign on has unpredictable effects.

+USER

Specifies that the userid signed on in the originating IMS region is propagated to the MSC receiving region. It is the administrator's responsibility to assure that the session user is allowed to sign on in both the originating and receiving regions and that the transaction is allowed in both regions.

+DEFAULT

Specifies that the DEFACID assigned by the receiving region FACILITY control option is used for MSC transaction validation for the MSC linkname.

For performance, specifying a single ACID for all in-bound transactions may be the best choice. If using PSB security, DBD security, or the application interface for MSC routed transactions, specifying +USER is a better choice. PSB, DBD, and application interface calls are message region security events and are always performed against the userid contained in the transaction's IOPCB. Specifying +USER provides consistent security between MSC transaction verification and the corresponding message region security.

If no values are defined for an MSC link in the IMSMSC field of the IMS control region ACID of the receiving IMS system, no CA Top Secret transaction validation is performed for non-directed routing transactions received on that link.

When MSC transactions are rejected by CA Top Secret because the user does not have the authority to execute them, the user in the originating system receives the message:

DFS2175 TRANSACTION CANCELLED BY MSC LINK EXIT ROUTINE

The complete violation is logged by CA Top Secret and may be found by running a violations report via TSSTRACK or TSSUTIL, on the MVS system where the transaction executed.

The likely causes for the failed transaction are:

• The ACID assigned to the transaction in the target region could not successfully sign on there. This may be due to the ACID being undefined, suspended, or lacking access to some resource, such as the facility.
• The ACID is not permitted to execute the transaction in the target system.

Example: MSC transactions

This example associates region ACID IMS81 with:

• The explicit link name MSC1$2 with propagated user id's from the originating region's terminal session
• The explicit link name MSC4$3 with fixed ACID LINK4$3
• The explicit link name MSC9$8 with the receiving region's facility DEFACID
• The implicit assignment of BADACID unable to sign on in the receiving region to any other link not explicitly defined in previously encountered links

  TSS ADD(IMS81) IMSMSC('MSC1$2(+USER), MSC4$3(LINK4$3), MSC9$8(+DEFAULT), ALL(BADACID)')
  

Transactions from APPC

Transactions can enter an IMS region from an APPC conversation. The security processing performed for transaction from APPC is controlled by the values chosen for the APPCSE initialization option.

The APPCSE option can be overridden using the IMS /SECURE command.

If the APPC security options request transaction validation, a SAF call is performed for transactions from APPC that provides CA Top Secret transaction validation in the TIMS resource class.

Transactions from OTMA

Transactions can enter an IMS region from an OTMA client. The security processing performed for transaction from OTMA is controlled by the values chosen for the OTMASE initialization option.

The OTMASE option can be overridden using the IMS /SECURE command..

If the OTMA security options request transaction validation, a SAF call is performed for transactions from OTMA that provides CA Top Secret transaction validation in the TIMS resource class.

Transactions from the OM QUE TRAN Command

Transactions can enter an IMS region from the OM QUE TRAN command. Transactions security for these transactions is the same as for transactions entered from terminals.

Transaction Password Reverification

Transactions that require additional security are defined to require the signon password to be entered with each use. This attempts to prevent certain sensitive transactions from being entered by an unauthorized individual at an unlocked terminal.

Examples: transaction password reverification

This example for LCF transactions requires password reverification to CA Top Secret by coding a V attribute when the transaction is defined to LCF:

TSS ADDTO(SUPR01) TRANSACTION(IMSPROD,(QUPD,PROD(V)))

This example for OTRAN, password reverification is indicated on the PERMIT by the ACTION (REVERIFY) parameter once the resource is owned:

TSS ADDTO(DEPT01) OTRAN(PROD)

TSS PERMIT(SUPR01) OTRAN(PROD)
                   ACTION(REVERIFY)

To supply a password with the transaction for either LCF or OTRAN, use the format:

trans(password) data

For example:

PROD(PRNX) SECRET 0447M

PROD

An authorized transaction.

PRNX

The user's signon password.

SECRET 0047M

Optional transaction parameters.