Extended Security Checking

Note: Extended security is not available when the Platform Server for z/OS is acting as a responder.

Before performing extended security checking, you must define the RACF resources that the Platform Server checks. The resource that is checked has a variable component that is based on the GLOBAL EXTENDED_SECURITY_RESOURCE parameter and a fixed component that does not change. Therefore, you can specify different resources for different Platform Server started tasks.

The Platform Server does not perform any resource checking if the GLOBAL EXTENDED_ SECURITY_CHECK parameter is set to NO. If the parameter is set to WARN, the checking is performed, and the request continues even if the resource check fails. If the parameter is set to ENFORCE, the checking is performed, and the request is terminated with errors if the resource check fails.

Where Is the RACROUTE Checking Performed

All RACROUTE AUTH requests are run on the same system as the Platform Server started task. If the batch or TSO request is through cross memory services (XMS), the request will be run within the ISPF or batch job. If the batch or TSO request is through SNA or TCP, the request will be run in the Platform Server started task.

In the following examples, the GLOBAL EXTENDED_SECURITY_RESOURCE parameter is set to the default value of $CFUSION, while the GLOBAL EXTENDED_SECURITY_CHECKING parameter is set to ENFORCE,ENFORCE to check authorization for Platform Server use and node security:

EXTENDED_SECURITY_RESOURCE=$CFUSION
EXTENDED_SECURITY_CHECKING=(ENFORCE,ENFORCE)

For more information, see GLOBAL Startup Parameters.

Checking Whether the User Is Authorized to Use the Platform Server

The Platform Server performs different checks when running under TSO and when running as a batch job.

When running under TSO, the Platform Server checks the following RACF resources:
$CFUSION.TRANSFER.AUTH.TSO
When running under batch, the Platform Server checks the following RACF resource:
$CFUSION.TRANSFER.AUTH.BATCH

You can define these resources individually using the following commands:

RDEFINE FACILITY $CFUSION.TRANSFER.AUTH.TSO UACC(NONE)
RDEFINE FACILITY $CFUSION.TRANSFER.AUTH.BATCH UACC(NONE)

You can give a user authorization to these facility classes using the following commands:

PERMIT $CFUSION.TRANSFER.AUTH.TSO CLASS(FACILITY) ID(userid) ACCESS(READ)
PERMIT $CFUSION.TRANSFER.AUTH.BATCH CLASS(FACILITY) ID(userid) ACCESS(READ)

If you want to assign both TSO and batch transfer rights to a user, then you can use the generic facility feature of RACF by specifying the following commands.

Note: RACF uses the most specific profile that matches the resource name. Therefore, if a batch or TSO resource is created, the generic resource is not checked when performing authorization checks for that resource.

RDEFINE FACILITY $CFUSION.TRANSFER.AUTH.* UACC(NONE)
PERMIT $CFUSION.TRANSFER.AUTH.* CLASS(FACILITY) ID(userid) ACCESS(READ)

Example 1:

In your organization, user ID CFMASTR is responsible for all file transfer activities, user ID CFTSO01 only needs the right to submit transfers from TSO, and batch user ID CFBAT01 is only used for batch transfers.

Define the facilities to RACF by using the following commands.
Note: The RDEFINE statements only needs to be performed once.
```
RDEFINE FACILITY $CFUSION.TRANSFER.AUTH.TSO UACC(NONE)
RDEFINE FACILITY $CFUSION.TRANSFER.AUTH.BATCH UACC(NONE)
```

Make these facilities be available to the relevant users.

For CFMASTR, issue the following commands:

PERMIT $CFUSION.TRANSFER.AUTH.TSO CLASS(FACILITY) ID(CFMASTR) ACCESS(READ)
PERMIT $CFUSION.TRANSFER.AUTH.BATCH CLASS(FACILITY) ID(CFMASTR) ACCESS(READ)

Now, CFMASTR can use either batch or TSO to initiate a transfer.

For CFTSO01 and CFBAT01, issue the following commands:

PERMIT $CFUSION.TRANSFER.AUTH.TSO CLASS(FACILITY) ID(CFTSO01) ACCESS(READ)
PERMIT $CFUSION.TRANSFER.AUTH.BATCH CLASS(FACILITY) ID(CFBAT01) ACCESS(READ)

Example 2:

Use a generic resource to grant access to users CFMASTR and CFUSER to initiate transfers through both batch and TSO.

RDEFINE FACILITY $CFUSION.TRANSFER.AUTH.* UACC(NONE)
PERMIT $CFUSION.TRANSFER.AUTH.* CLASS(FACILITY) ID(CFMASTR) ACCESS(READ)
PERMIT $CFUSION.TRANSFER.AUTH.* CLASS(FACILITY) ID(CFUSER) ACCESS(READ)

Note: The RDEFINE statement has only to be performed once.

It is a good practice that before running Platform Server extended security in ENFORCE mode, it is run in WARN mode, in this way any security issues can be corrected before production transfers are cancelled.

NODE Level Security Checking

The Platform Server incorporates the node name into a resource to check if a user is authorized to initiate transfers to a particular node. When validating access to a particular node, you can also differentiate between a send transfer and a receive transfer to the specific node by using the following commands:

$CFUSION.TRANSFER.nodename.INIT.SEND
$CFUSION.TRANSFER.nodename.INIT.RECEIVE

These resources can be defined to RACF by using the following commands:

RDEFINE FACILITY $CFUSION.TRANSFER.nodename.INIT.SEND UACC(NONE)
RDEFINE FACILITY $CFUSION.TRANSFER.nodename.INIT.RECEIVE UACC(NONE)

In place of the nodename, a reserved IPADDR string can be used to restrict a user from specifying the IP address or IP name on the transfer. This IPADDR string can be used to force users to only use the Platform Server defined nodes when initiating a transfer. The RACF resources used to protect against usage of an IP address or IP name are following:

$CFUSION.TRANSFER.IPADDR.INIT.SEND
$CFUSION.TRANSFER.IPADDR.INIT.RECEIVE

These resources are defined to RACF by using the following commands:

RDEFINE FACILITY $CFUSION.TRANSFER.IPADDR.INIT.SEND UACC(NONE)
RDEFINE FACILITY $CFUSION.TRANSFER.IPADDR.INIT.RECEIVE UACC(NONE)

You can use the previous definitions to protect who can perform a send or receive transfer using an IP address or IP name. To protect against all usage of an IP address or IP name, use the following RACF definition:

RDEFINE FACILITY $CFUSION.TRANSFER.IPADDR.** UACC(NONE)

Note: RACF uses the most specific profile that matches the resource name. Therefore, if a specific resource is created, the generic resource is not checked when performing authorization checks for that resource.

Example 1:

The following RDEFINE and PERMIT commands protect the use of an IP address or IP name for all users except the CFADMIN ID:

RDEFINE FACILITY $CFUSION.TRANSFER.IPADDR.** UACC(NONE)
PERMIT $CFUSION.TRANSFER.IPADDR.** CLASS(FACILITY) ID(CFADMIN) ACCESS(READ)

Example 2:

The following RDEFINE and PERMIT commands protect the use of all nodes except the CFADMIN ID:

RDEFINE FACILITY $CFUSION.TRANSFER.** UACC(NONE)
PERMIT $CFUSION.TRANSFER.** CLASS(FACILITY) ID(CFADMIN) ACCESS(READ)

Example 3:

The following RDEFINE and PERMIT commands gives the CFOPER ID the ability to initiate a Platform Server send transfer to all nodes:

REDEFINE FACILITY $CFUSION.TRANSFER.*.INIT.SEND UACC(NONE)
PERMIT $CFUSION.TRANSFER.*.INIT.SEND CLASS(FACILITY) ID(CFOPER) ACCESS(READ)

Example 4:

The following RDEFINE and PERMIT commands gives the CFNY001 ID the ability to send to and receive from the node CFNY:

RDEFINE FACILITY $CFUSION.TRANSFER.CFNY.INIT.* UACC(NONE)
PERMIT $CFUSION.TRANSFER.CFNY.INIT.* CLASS(FACILITY) ID(CFNY001) ACCESS(READ)

Example 5:

The following RDEFINE and PERMIT commands gives the CFLA001 ID the ability to send to and receive from the node CFLA:

RDEFINE FACILITY $CFUSION.TRANSFER.CFLA.INIT.* UACC(NONE)
PERMIT $CFUSION.TRANSFER.CFLA.INIT.* CLASS(FACILITY) ID(CFLA001) ACCESS(READ)

Note: It is a good practice that before running Platform Server extended security in ENFORCE mode, you run it in WARN mode. In this way, any security issues can be corrected before production transfers are cancelled.