Protecting Resources › Online Transaction Protection

Online Transaction Protection

CA Top Secret secures online transactions:

• Through OTRAN (resource) security.

  The OTRAN resource class allows transactions-which are ordinarily considered unowned-to be administered as owned resources. Security can be administered on a decentralized, application‑by‑application basis, and access to each transaction can be tailored with the same flexible restriction options available for other resources.

• By the Limited Command Facility (LCF).

  Through LCF, you can assign authorizations and restrictions to transactions on a user‑by‑user basis without impacting other users. Transactions controlled with LCF are not owned. If factors such as administrative scope and resource auditing capabilities are considered highly important for your security environment this may not be the best approach.

Implementing OTRAN Security

The OTRAN resource name is shared by all CICS, CA‑IDMS, and IMS facilities. Protecting a transaction using OTRAN for a CICS region results in transactions of the same name being protected in all CICS, CA‑IDMS, and IMS regions under the control of CA Top Secret.

When securing transactions with OTRAN:

• OTRAN protects the transaction IDs across all facilities.
• Once a transaction is owned, it is protected from use by any user in any facility. Consider all the users who may need that transaction before using the OTRAN resource class.
• Transaction security through the OTRAN resource class overrides LCF protection. Once a transaction is owned, any appearance of it in an LCF list, whether inclusive or exclusive, is ignored.
• A transaction protected via OTRAN will not go through LCF checking.
• All features of owned resources are supported by OTRAN (such as TSS WHOHAS and TSS WHOOWNS).
• Screen Level Protection (SLP) can be enabled by associating a MAP record with an OTRAN or PPT resource.
• Password reverification is supported by OTRAN.
• OTRAN is a generic resource by default, unlike LCF. It is impossible to specify an LCF rule which is both GENERIC and employs password reverification, it is straightforward to do so for OTRAN.
• Although OTRAN may be set with the MASK RDT attribute, this is not supported in the IMS environment. Clients employing TSS security in IMS are cautioned not to set the MASK attribute in the OTRAN RDT definition.

OTRAN Security Setup

Transactions must be owned before being authorized.

Example: set up OTRAN security

This example has the Payroll Department (PAYDEPT) own the transaction PAYR:

TSS ADDTO(acid) OTRAN(transaction)

TSS ADDTO(PAYDEPT) OTRAN(PAYR)

OTRAN Ownership Removal

CA Top Secret will not remove ownership unless all permissions are revoked.

To remove ownership of a transaction

1. Revoke all permissions for the resource. For example:

   TSS REVOKE(PAYPROG) OTRAN(PAYR)
   

2. Remove the ownership of the transaction. For example:

   TSS REMOVE(PAYDEPT) OTRAN(PAYR)
   

OTRAN Generic Prefixing

OTRAN resources can be designated using generic prefixes. Once a prefix is owned, any transaction beginning with that prefix is protected and must be permitted to other ACIDs.

Example: generic prefixing with OTRAN

This example gives ownership of transactions that begin with the prefix PAY to the ACID PAYDEPT:

TSS ADDTO(PAYDEPT) OTRAN(PAY)

Authorize OTRAN Access

Use the PERMIT command function to allow designated users to use the specified transactions in an unlimited or restricted manner.

Example: authorize OTRAN access

This example allows a user whose ACID is PAYPROG to access the transaction PAYR:

TSS PERMIT(PAYPROG) OTRAN(PAYR)

OTRAN Program Pathing

Program pathing can restrict the access of certain transactions to designated programs.

Program pathing is not supported by all facilities.

Example: OTRAN program pathing

This example allows PAYPROG to start the transaction PAYR through the PAYGRP program:

TSS PERMIT(PAYPROG) OTRAN(PAYR)
                    ACCESS(EXECUTE)
                    PRIVPGM(PAYGRP)

Password Reverification with OTRAN

To reduce the chance of someone taking advantage of an unattended terminal, use reverification to force the terminal's user to supply his password to execute a particular transaction. Add ACTION(REVERIFY) to the PERMIT. Reverification is only supported for CICS and IMS.

Example: password reverification

This example forces reverification:

TSS PERMIT(USR01) OTRAN(PAYR)
                  ACTION(REVERIFY)