1.2 Component Details
This section describes the components of the z/OS RACF driver package. Topics include
Figure 1-1 Component Overview
1.2.1 RACF Event Subsystem
The RACF Event Subsystem uses standard RACF exits to capture events of interest and place them on a cross memory queue. The Change Log Started Task moves events to the Change Log data set. The LDXSERV TSO command provides the Publisher channel with access to the Change Log data set. The LDXISSUE TSO command is used by the Subscriber channel to issue TSO commands and capture their output.
RACF Exits
The RACF exits detect RACF activity of interest and place events in a cross memory queue. When the RACF exits place an event in the cross memory queue, they notify the Change Log Started Task. The Change Log Started Task then moves the event to the Change Log data set.
Each system that shares a RACF database must run the RACF Event Subsystem RACF exits.
The Common Command exit: Receives control when a RACF command is issued. The RACF Event Subsystem uses this exit to create an event for commands that affect users or groups.
The RACROUTE REQUEST=VERIFY(X) (RACINIT) postprocessing exit: Receives control after user verification. The RACF Event Subsystem uses this exit to create an event when a user changes the password upon logging on to the system.
Cross Memory Queue
The cross memory queue is an in-storage buffer that holds events. Events are added to the cross memory queue by the RACF exits, and removed from the queue by the Change Log Started Task. The cross memory queue is located in Subpool 231 (fetch-protected ECSA).
Change Log Started Task
The Change Log Started Task is notified of events added to the cross memory queue by the RACF exits, and moves them to the Change Log data set.
Each system that shares a RACF database must run the Change Log Started Task. The Change Log Started Task must be started as part of your normal z/OS system initialization procedure and stopped during normal system shutdown.
Change Log Data Set
The Change Log data set stores events for processing by the Publisher channel.
The Change Log data set is a standard z/OS direct access (DSORG=DA) data set. There is one Change Log data set for the set of systems that share a RACF database. The Change Log data set must reside on a shared device unless the RACF database is not shared.
LDXSERV TSO Command
LDXSERV is an APF-authorized TSO command that is used by the driver through a Telnet interface to access and control the RACF Event Subsystem.
The Publisher channel calls LDXSERV to retrieve the next event from the Change Log data set, and to mark an event complete after processing is finished.
The Subscriber channel calls LDXSERV upon startup to identify itself to the RACF command exit. This prevents the RACF command exit from generating events for RACF commands issued by the Subscriber channel (loopback).
Syntax
LDXSERV [ STATUS | GETNEXT | MARKDONE EVENTID(token) | NOLOG | LOG ]
STATUS: Reports the status of the RACF Event Subsystem in an XML document.
GETNEXT: Obtains the next event from the Change Log data set.
MARKDONE: Marks the designated event complete in the Change Log data set.
NOLOG: Causes the RACF command exit to not log events for commands that originate from the current address space. The Subscriber channel issues this command at logon to prevent loopback.
LOG: Removes the address space token that prevents RACF commands from being logged.
LDXISSUE TSO Command
LDXISSUE is a TSO command that is used by the Subscriber channel through a Telnet interface to issue commands and capture their output.
Syntax
LDXISSUE command
LDXISSUE executes the supplied TSO command, and returns the command output and return code in an XML document.
1.2.2 Publisher Channel
The Publisher channel obtains RACF events from the Change Log data set, encodes them as XDS documents, and passes them to the Identity Manager engine. The Publisher channel marks events complete in the Change Log data set after they have been processed.
The Publisher channel accesses the Change Log data set by issuing LDXSERV TSO commands through a Telnet interface. A logon ID with appropriate authority is required for the Telnet interface.
1.2.3 Subscriber Channel
The Subscriber channel receives XDS command documents for users and groups from the Identity Manager engine, converts them to RACF TSO commands, and executes them.
The Subscriber channel does not perform validation of attribute values in the XDS command document. If the requirements of RACF are not met, the results of the RACF commands are unpredictable.
The Subscriber channel can also execute arbitrary TSO commands generated in the Command class by the policies. For details, see Using the Subscriber Channel Command Class.
The Subscriber channel uses the LDXISSUE command through a Telnet interface to issue TSO commands. A logon ID with appropriate authority is required for the Telnet interface.
1.2.4 The z/OS RACF Schema
The Identity Manager 3.6.1 driver for RACF uses the z/OS RACF schema to describe the attributes of user and group profiles in RACF. For a description of the z/OS RACF schema, see Section A.1, z/OS RACF Schema. For a description of how attributes in the z/OS RACF schema relate to RACF command parameters, see Section A.2, RACF Command Parameter Mapping and Section A.3, Driver Processing of Attributes and Commands.
1.2.5 Auxiliary Classes
The Identity Manager Driver for z/OS RACF provides auxiliary classes to add z/OS RACF schema attributes to User and Group objects in eDirectory. You can use the driver to maintain the RACF attributes between corresponding users and groups in RACF and eDirectory.
1.2.6 Configuration
The behavior of an Identity Manager driver is governed by its configuration of options, policies, and filters. The configuration of the z/OS RACF driver is stored in its driver object in eDirectory.
A preconfigured starter set of sample policies is provided with the Identity Manager driver for z/OS RACF. You must customize these as appropriate for your needs.
For a description of the processing of the sample policies, see Section 1.4, Processing Description. For details about customizing the driver, see Section 3.0, Customizing the Driver.