Is JES(NOVERIFY) supported under Top Secret r16?
Article ID: 40654
Updated On:
Products
Issue/Introduction
Is JES(NOVERIFY) supported under Top Secret r16?
Environment
Component: TSSMVS
Resolution
Top Secret Release 16 BATCH Job Considerations
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 different in Release 16.
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 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. I f 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.
BATCH Considerations
Top Secret views BATCH as a facility that must be protected and authorized for use. Each batch job must be associated with an ACID and a password so that Top Secret can tell which resources it can access and how they can be accessed.
A batch job can enter the system through either an internal or external reader. When the job is submitted through an internal reader it is described as being submitted online, even when the job is being submitted by an unattended batch job or started task.
There are two methods for assigning ACIDs to batch jobs submitted online:
- Through the SUBACID control option. The SUBACID control option automatically insert a derived ACID into the USER= parameter in the batch job's JOB statement. The value inserted into the USER= parameter is the ACID under which the batch job will run.
- Directly through the USER= parameter on the JOB statement. If the USER= parameter on the JOB statement has a value submitted with the job, this value becomes the job's designated ACID and Top Secret does not check the SUBACID control option. When you specify an ACID in the USER= parameter of the JOB statement, it overrides the SUBACID control option.
Using the SUBACID Control Option
Use the SUBACID control option to indicate how Top Secret derives an ACID for batch jobs that are submitted by the following methods:
- Through an online terminal
- From another batch job
- From a started task
This control option has the following format:
SUBACID(J|U,n) Indicates that the first n characters of the jobname parameter on the job card is used as the ACID, unless USER=acid is present.
SUBACID(J,n) Specifying SUBACID(J,7) restricts jobnames to the user's userid plus one character. This will occur unless the user is explicitly PERMITted to submit other ACIDS.
SUBACID(U,n) Indicates that the first n characters of the logged on user's ACID, or of the ACID associated with the started task, is used as the ACID for the batch job.
Default: SUBACID(U,7).
Authorizing networking jobs
This topic contains information about how to use CA-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 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)
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)
Feedback
