How JES(NOVERIFY) works with Apar RO88932 applied in Top Secret Release 16.0.

Products

• Top Secret
• Top Secret - LDAP

Issue/Introduction

Initially Top Secret Release 16 only supported JES(VERIFY).  With Apar RO88932 applied, Top Secret supports the JES(VERIFY) and JES(NOVERIFY) control options. However, JES(NOVERIFY) functions differently in Release 16.

Environment

Release:
Component: TSSMVS

Resolution

Top Secret Release 16 BATCH Job Considerations:

JES(VERIFY) is the default and indicates Top Secret verifies USER and PASSWORD parameters implicitly without inserting these parameters into the JOB JCL statement. This is the default for JES2 and JES3.  If a USER is present in the JOB statement, then the USER is checked to see that the submitter is cross-authorized. If submission is allowed, no password processing will take place unless the password is explicitly coded. For information, see the Implementation: Other Interfaces Guide.    

For Release 15, JES(NOVERIFY) indicated Top Secret will insert USER and PASSWORD information explicitly into the JOB JCL if it is not already present. We recommend that you do not include explicit USER and PASSWORD information, as this can be intercepted from spool.

With Top Secret Release 16 with Apar RO88932 applied, Top Secret supports the JES(NOVERIFY) control option, but Top Secret will only insert the USER= parameter on the JOB card. PASSWORD= will no longer be inserted.  If you used JES(NOVERIFY) with Release 15 then you will have to make changes to your security environment before migrating to Release 16 if you use NJE to execute jobs at remote nodes.  You must specify one or more permits in the NODES Resource class to allow jobs received via NJE to execute.  You may also have to add cross-authorization permits on remote nodes that jobs are sent to.

In R15 with JES(NOVERIFY) if you submit a job to run on a remote node and the job has USER= on the JOB card, TSS inserts the PASSWORD= parameter on the JOB card.  On the remote system, you do not need any permits in the NODES resource class for the job to run because TSS will process it as if you had a NODES permits with ACCESS(READ).  TSS will validate user and password and the job will run.

In R16, to provide a more secure environment, TSS will no longer insert PASSWORD= on the job card, so if there is no NODES permit on the remote system, TSS will process the job the same as if there was a NODES permit with ACCESS(READ).  TSS will try to validate user and password.  Since there is no password on the JOB card, TSS will fail the job with DRC 007 (password missing).  In R16 you need a NODES permit with at least UPDATE access in order for the job to run.  If the permit has ACCESS(UPDATE) then the submitting user must also be cross-authorized (on the remote system) to the acid specified on the USER= parameter.  If the NODES permit on the remote system has ACCESS(ALL) then no cross-authorization permit is needed. 

Authorizing networking jobs:

This topic contains information about how to use Top Secret to ensure that all work entering or leaving your node complies with your installation's security policy. You can control:

• Jobs and data received from other nodes in a network.

• The extent of security validation performed at your node.

JES2 does not validate work passing through your node on its way to another node in the network, but it does protect the work from unauthorized access while the work is temporarily stored at your node.

To provide security for Networking Job Entry (NJE), define resources in the NODES class (for inbound work) or the WRITER class (for outbound work) to enforce your installation's networking security policy.

Before you can provide this information, you must first decide whether you want to protect inbound work, outbound work, or both.

Network Job Entry (NJE) Job Validation:

Nodes processing is used to control the execution of incoming NJE jobs and can be used 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, 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 the following examples node ALPHA is the local node and node BETA is a remote node. 

*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.

 

*In this example, any job submitted from node BETA can run without any password checking, but the submitting user must be authorized for the execution user on node ALPHA:

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

ACIDs with Limited Access: 

To run jobs from an ACID having limited access to resources on the node ALPHA, use the NJEACID parameter on the NODES permits.

Example: limit access ACID

*In this example, jobs submitted on node BETA will run on node ALPHA with the userid BETAACID. 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 node BETA is also named CA7, 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 supposes 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) 

Authorizing outbound work:

You can use TSS to control whether a specific node can receive work (jobs or SYSOUT).

For NJE, JES2 ensures that the originator of outbound work is authorized to send the work to the target node. To activate protection for a node define resources in the WRITER class for each node that you want to protect. The format of the resource name is JES2.NJE.node.

*This example allows USER01 to route jobs to the ALPHA node.

 TSS PERMIT(USER01) WRITER(JES3.NJE.ALPHA)