Node Protection

A node is a point in a network defined by a symbolic name.

To protect a node

Establish ownership using TSS CREATE/ADDTO. For example:
```
TSS ADDTO(DEPT01) NODES(ALPHA.USERJ*)
```

Authorize access to the job using TSS PERMIT. For example:

TSS PERMIT(ALL) NODES(ALPHA.USERJ.)
                ACCESS(NONE)

Example: protect a node

This example assigns the submitting ACID as the owner of the output of any job originally submitted from this node, and the ACID specified on the NJEUSR control option for all other output received.

TSS PERMIT(ALL) NODES(*.USERS.)
                ACCESS(READ) 
                NJEACID(&SUSER)

Generic Prefixing for Nodes

Generic prefixing lets you group a set of similar nodes together and define them with one prefix. Once a prefix is owned, any node beginning with that prefix is protected and must be permitted to other ACIDs.

Example: protect a node using generic prefixing

This example gives ownership of nodes beginning with the prefix ALPHA to the ACID SYSGROUP.

TSS ADDTO(SYSGROUP) NODES(ALPHA)

Masking Nodes

Masking can be used to group nodes whose names share similar characteristics. These shared patterns can then be used as the operands of the NODES parameter in TSS PERMIT entries.

A masked node is treated by CA Top Secret like a generic prefix. Any node that begins with a mask is considered a match by the security validation algorithm, and the associated access authorizations are honored.

Node Access Levels

The access levels that can be specified for nodes are:

ALL

(Default) Accept all jobs.

UPDATE

If a validated security token exists for the submitting user, that userid can be propagated. If the submitting user is not the same as the owner, a successful ACID cross‑authorization check can be used to eliminate the need for further verification. In all other cases, normal verification is used.

READ

The job goes through normal verification, including password checking if appropriate.

CONTROL

Accept the job as valid without further verification of the user.

For example, if any job submitted from node BETA is to run without any password checking, enter:

TSS PERMIT(ALL) NODES(BETA.USERJ)
                ACCESS(CONTROL)

NONE

Job is failed.

Network Job Entry (NJE) Job Validation

Nodes processing is used to control the execution of incoming NJE jobs and to assign a userid as the owner of the job on the target node (if necessary). Control is obtained through the NODES resource class.

Userid Owner Identification

When a node receives a job from NJE:

The owning userid is always identified first.
The identified owner is usually the submitting userid.
If USER= is coded on the job card, that userid is used instead
If the owning userid is undefined on the receiving node the ALL Record is used in the checking process.
If the submitting node is the same as the value specified in the JESNODE control option, the job is treated as a local job and no nodes processing takes place.

After the owner is identified, CA Top Secret generates the following resource:

nodename.USERJ.userid

nodename: The name of the submitting node.
USERJ: Indicates that the job is controlled by the submitting userid.
Userid: The identified owner of the job.

Access Level Checking

Once the userid is identified the highest access level allowed of the generated resource is determined. If that access level is:

NONE: The job is failed.
READ: The job goes through normal verification, including password checking (if appropriate).
UPDATE: If a validated security token exists for the submitting user, that userid can be propagated. If the submitting user is not the same as the owner, a successful ACID cross‑authorization check may be used to eliminate the need for further verification. In all other cases, normal verification is used.
CONTROL or higher: Accept the job as valid without further verification of the user.

Examples: determine access levels

In this example, node ALPHA is not allowed to execute jobs on node ALPHA.USERJ:

TSS PERMIT(ALL) NODES(ALPHA.USERJ.)
                ACCESS(NONE)

In this example, userid X123 is allowed to execute jobs on node ALPHA.USERJ, by creating a validated security token:

TSS PERMIT(ALL) NODES(ALPHA.USERJ.X123) 
                ACCESS(UPDATE)

In this example, any job submitted from node BETA can run without any password checking:

TSS PERMIT(ALL) NODES(BETA.USERJ) 
                ACCESS(CONTROL)

In this command, the access level can be specified as ALL with no difference in how the processing works.

ACIDs with Limited Access

To run jobs from an ACID having limited access to resources on the node BETA.USERJ, use the NJEACID parameter.

Example: limit access ACID

In this example, in addition to checking the appropriate access level, the value of the NJEACID parameter is substituted for the original owning userid:

TSS PERMIT(ALL) NODES(BETA.USERJ.) 
                ACCESS(CONTROL) 
                NJEACID(BETAACID)

In this command, the access level can be specified as ALL with no difference in how the processing works.

Identical ACIDs

If ACID CA7 is in use on the local node and another user on NODE2 is also named CA7, CA Top Secret translates the ACID of the incoming job.

The user must be validated on the sending system for the job to be accepted.

Example: identical ACIDs

This example translates the userid for the incoming job to a userid CA7NODE2:

TSS PERMIT(CA7) NODES(NODE2.USERJ.CA7) 
                NJEACID(CA7NODE2) 
                ACCESS(UPDATE)

Alternate Way to Implement Nodes

There is an alternate method of implementing nodes.

Example: alternate node implementation

This example suppose that users defined to the profile TECHSUP have access to sensitive resources. This entry prevents ACIDs from being used on NJE jobs or, alternatively, allows the jobs to run under a default user called DEFUSER with a lower access level:

TSS PERMIT(TECHSUP) NODES(*.USERJ.) 
                    ACCESS(NONE)

TSS PERMIT(TECHSUP) NODES(*.USERJ.) 
                    ACCESS(CONTROL) 
                    NJEACID(DEFUSER)