Previous Topic: Command Propagation FacilityNext Topic: CPF-Related Control Options


CPF Architecture

To use CPF, the security administrator must first be aware of all remote CPUs and the ACIDs defined to them. Most Security Files are essentially identical; those defined to one site can be defined to a remote site as well. Security Files that aren't identical can have additional ACIDs, permissions, and/or resource ownership definitions which must be taken into account. This can become a difficult task for the security administrator responsible for maintaining user information. If this is the case, you may want to consider using automatic propagation based on default nodes (DEFNODES) for ACIDs.

Implicit and Explicit Targeting

CPF lets you automatically synchronize Security Files on multiple nodes through the propagation of TSS commands as well as user‑initiated changes— such as suspension and password changes. Security administration propagation can be implicit (by using the CPF control options to set system‑wide propagation rules) or explicit (by using the CPF command keywords to set propagation rules on a command‑by‑command basis).

The designated CPF control option values specified in each Parameter File determine the implicit target nodes to be used when a command is issued from that particular node. For example, if the CPF control options for NODEA identify implicit target nodes of NODEB, NODEC, and NODED, whenever a command is issued from NODEA that command is automatically sent to NODEB, NODEC, and NODED.

By using the CPF command keywords, a security administrator can override the targets designated by the control options. For example, even though the control options for NODEA identify implicit targets of NODEB, NODEC, and NODED, the security administrator can use the TARGET keyword to indicate that a particular command should only be propagated to NODEB.

More information:

CA Top Secret Command Keywords Used With CPF

Synchronous and Asynchronous Processing

In addition to designating target nodes for a command, you can also indicate how that command is processed. By using the appropriate control options and command keywords, you can process on a synchronous or asynchronous basis as described below.

Synchronous

Allows the TSS command to execute simultaneously throughout the network. CA Top Secret waits for the command response to return from the remote node before continuing.

Asynchronous

Allows the TSS command to execute on a selective basis throughout the network. This means that CA Top Secret does not have to wait for a response from each node to resume processing. All commands transmitted through asynchronous processing are retained in a CPF Recovery File.

These options are independent and can be used separately or together. The synchronous or asynchronous processing of commands and the specific targeted nodes are initially determined by control option settings. Later, these values can be changed using the appropriate TSS command keywords.

More information:

CA Top Secret Command Keywords Used With CPF

Defining CPF nodes

CPF nodes are defined as CPFNODE elements on the NDT system record in the CA Top Secret security file. CPF nodes are grouped on the NDT record by system id, to allow multiple CA Top Secret systems use separate CPF node definitions. For downward compatibility, this release of CA Top Secret, will also support defining CPF nodes using the CPFNODES control option. Once a CPF node is defined to the NDT record, a control option definition for the same node name is ignored.

CPF node definitions in the NDT record can be created or modified at any time after CA Top Secret starts up. The START & REFRESH commands described later in this chapter are used to activate newly defined CPF nodes, or to apply new processing options to existing active CPF nodes. When refreshing an individual node, CPF processing for other nodes is not interrupted.

The following example shows how to set up the NDT CPFNODE definitions for system SYS1, to allow sending and receiving CPF commands and passwords to remote system SYS2:

TSS ADD(NDT) CPFSYSID(SYS1) RECVCMDS(YES) CPFTARGET(LOCAL)
TSS ADD(NDT) CPFSYSID(SYS1) CPFNODE(SYS2) JOURNAL(YES) RECEIVE(ALL)  SEND(ALL)

Note: If all CPF related control options are migrated from the control options parameter file to the NDT, control option CPF(ON) or CPF(OFF) is required in the parameters file for CPF to initialize using the NDT based definition. If neither is specified, CPF will not initialize and cannot be activated unless CA Top Secret is recycled. CPF(ON) activates CPF as soon as CA Top Secret is started up. CPF(OFF) will start CA Top Secret with CPF inactive, however, CPF may be later activated via a TSS MODIFY(CPF(ON)) command. Adding a new CPF node to an active CA Top Secret system, also requires adding a NODE definition to CAICCI.

Administrative Authority

In all cases, administrative authority and scope of the security administrator is verified at the sending and target nodes before the command is successfully applied to the targeted Security Files. This is an important level of control over remote administration. To enter TSS commands with a targeted destination, you need MISC2(TARGET) authority.

In addition to propagating changes, CPF allows the security administrator to view the contents of Security Files in remote nodes. This viewing is completely secure since scope is verified at both locations, allowing the administrator or auditor to review the security information for which he or she is responsible at all nodes in the CPF domain. CPF also encrypts the data that it sends between nodes.

Propagated administration commands execute on the remote system using the authority and scope of the user as defined on the remote system, and not from the originating system. For example, if a user who is defined as an SCA on one system propagates a TSS command to a system where that user is defined only as a USER, then the command is limited to the USER authority.

User initiated (versus administrator initiated) password changes propagated through CPF cause the user's password to change at each node where the change is sent, provided that the user's existing passwords are the same. The password will not change at nodes where the existing passwords aren't identical or aren't synchronized. This prevents one user from changing the password of an identically named ACID on another node that is used by another person.