Figure 1 illustrates the journey of
a directed RACF® command through
an RRSF network. The network contains two RRSF nodes, NODEA and NODEB,
that use APPC to communicate. The LU name for NODEA is LUA, and the
LU name for NODEB is LUB. User ID PAT on NODEA has a peer user ID
association defined with user ID PATL on NODEB. User ID PATL is defined
on NODEB and has authorization to delete user DUDLEY. The prefix for
the workspace data sets is RRSF.QUEUES for both NODEA and NODEB.
Figure 1. A directed command traveling through an RRSF
network that uses APPC
A directed command is processed as follows:
- User PAT on NODEA issues the command DELUSER DUDLEY AT(NODEB.PATL).
- RACF on NODEA
determines that the command is a directed command, and verifies that:
- User ID PAT on NODEA has an association defined with user ID PATL
on NODEB.
- User ID PAT on NODEA is authorized (via an RRSFDATA
profile) to direct commands to NODEB.
If both conditions are met, RACF sends
the command to the RACF subsystem
address space.
- The RACF subsystem address
space processes the command as follows:
- RACF on NODEA masks the
command using the Commercial Data Masking Facility (CDMF) algorithm
implemented with a fixed key. The
purpose of this masking is to protect against inadvertent casual viewing
of the data while it is in the workspace data sets and during transmission.
(This protection supplements the protection that classes such as APPCSERV
and APPCLU provide to the data during transmission, and that RACF DATASET authorization provides
to the data while it is in the workspace data sets.)
- RACF on NODEA saves a copy
of the masked command in the OUTMSG workspace data set, RRSF.QUEUES.LUA.LUB.OUTMSG.
- If the connection between NODEA and NODEB is operative, RACF on NODEA passes the command
to APPC/MVS. If the connection is dormant, RACF waits for it to become operative before
passing the command to APPC/MVS.
- APPC/MVS transmits the masked command from NODEA to NODEB.
- APPC/MVS passes the masked command to RACF on NODEB.
- RACF processes
the command as follows:
- RACF on NODEB saves a copy
of the masked command in the INMSG workspace data set RRSF.QUEUES.LUB.LUA.INMSG.
- RACF on NODEB notifies RACF on NODEA by way of APPC/MVS
that the command has been written to the INMSG workspace data set.
- RACF on NODEA deletes the
command from the OUTMSG workspace data set, RRSF.QUEUES.LUA.LUB.OUTMSG.
Note that the deletion does not occur until after the command is received
on NODEB to prevent loss of the command if transmission errors occur,
thus ensuring data integrity.
- RACF on NODEB unmasks the
masked command.
- RACF on NODEB
verifies that user ID PATL exists on NODEB and that PATL on NODEB
has an association with PAT on NODEA.
- RACF on NODEB runs the
command in the RACF subsystem
address space with the authority of PATL, and deletes user DUDLEY.
- RACF on NODEB masks the
command output using the CDMF algorithm.
- RACF on NODEB saves a copy
of the masked output in the OUTMSG workspace data set RRSF.QUEUES.LUB.LUA.OUTMSG.
- If the connection between NODEA and NODEB is operative, RACF on NODEB passes the masked
output to APPC/MVS. If the connection is dormant, RACF waits for it to become operative before
passing the command output to APPC/MVS.
- APPC/MVS transmits the masked command output from NODEB to NODEA.
- APPC/MVS passes the masked command output to RACF on NODEA.
- RACF on NODEA saves a copy
of the masked command output in the INMSG workspace data set RRSF.QUEUES.LUA.LUB.INMSG. RACF on NODEA notifies RACF on NODEB by way of APPC/MVS
that the output has been received. RACF on
NODEB deletes the command output from the OUTMSG workspace data set
RRSF.QUEUES.LUB.LUA.OUTMSG.
- RACF on NODEA unmasks the
command output, stores it in user ID PAT's RRSFLIST data set, and
deletes the saved copy in the INMSG workspace data set RRSF.QUEUES.LUA.LUB.INMSG.
- RACF on NODEA uses SEND
to notify user ID PAT that the command has completed.
If user PAT on NODEA had originally issued the command
DELUSER
DUDLEY ONLYAT(NODEB.PATL), using the ONLYAT keyword instead
of the AT keyword, the processing for the command would have been
the same, with the following exceptions:
- Step 2.b would have been replaced
by a check that user ID PAT on NODEA had SPECIAL authority.
- Step 6.e would have additionally
checked whether user ID PATL on NODEB had SPECIAL authority.
z/OS Security Server RACF System Programmer's Guide
Copyright IBM Corporation 1990, 2014