Novell Doc: Identity Manager 3.6.1 Driver for Mainframes: CA Top Secret Implementation Guide

1.1 Driver Architecture

The driver synchronizes information between the Identity Vault and the security system on the connected z/OS system.

The Identity Manager detects relevant changes to identities in the Identity Vault and notifies the Subscriber component of the driver. After customizable policy processing, events are sent to the Subscriber channel of the driver shim started task on the connected system. The Subscriber shim securely passes the information to customizable REXX execs that perform the required actions.

Standard security system exit routines capture password and other changes and place them on a memory queue. The change log started task moves events from the memory queue to the change log data set, where they are stored for processing. At configurable intervals, the Publisher shim polls the change log for events and submits them to the Metadirectory engine. The Metadirectory engine processes these events using customizable policies, and posts relevant changes to the Identity Vault.

The following illustration shows an overview of the architecture.

Figure 1-1 Top Secret Driver Architecture

The following topics describe the driver architecture in more detail:

1.1.1 Publisher Channel

The Publisher shim periodically examines the change log for events. When the Publisher shim finds events in the change log, it decrypts, processes, and sends them to the Metadirectory engine in XDS format over a Secure Sockets Layer (SSL) network link. The Metadirectory engine applies policies, takes the appropriate actions, and posts the events to the Identity Vault.

z/OS object names are uppercase. The Publisher Placement policy converts object names to lowercase.

Security System Exit Routines

Top Secret provides an installation exit named TSSINSTX. The driver uses this exit to detect activity of interest and to place events in the memory queue. When the driver exit routines place an event in the memory queue, they notify the change log started task. The change log started task then moves the event information to the change log data set. Each system that shares the security system database must run the exit routines provided by the driver in module IDMTSSIX.

The driver exit routines perform the following tasks:

Monitor password changes from the local security system and record user and password information in the memory queue.
Monitor security system administrative commands entered by users, either directly from the TSO command line, or as generated by the administrative panels. The exit routines record these commands and related information, such as the issuer and time stamp, in the memory queue.

Memory Queue

The memory queue is an encrypted, in-storage buffer that holds events. Events are added to the memory queue by the security system exit routines, and are removed from the queue by the change log started task. The 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 memory queue by the driver exit routines and moves them to the change log data set.

Each system that shares a security system 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 started task removes encrypted events from the memory queue and stores them in the change log data set for processing by the Publisher shim. The Publisher shim removes events from the change log at configurable intervals and submits them to the Metadirectory engine. If communication with the Metadirectory engine is temporarily lost, events remain in the change log until communication becomes available again.

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 the security system database. The change log data set must reside on a shared device unless the security system database is not shared.

1.1.2 Subscriber Channel

The Subscriber channel of the driver shim started task receives XDS command documents from the Metadirectory engine, stores them using z/OS name/token callable services, then calls the appropriate REXX execs to handle the command.

The Subscriber Creation policy converts object names to uppercase before the command documents are sent to the Subscriber. z/OS object names are uppercase.

The Subscriber shim calls the LDXSERV command on startup to identify itself to the security system exit routines for loopback detection. This prevents the exit routines from generating events for commands issued by the Subscriber shim.

SAFQUERY Command

SAFQUERY is an APF-authorized TSO command that is used by the driver to query security system information. SAFQUERY uses the RACROUTE macro for z/OS to retrieve information from the security system database through the system authorization facility (SAF).

REXX Execs

The provided REXX execs support adds, modifies, deletes, and renames for User and Group objects, and handle password synchronization. The REXX execs use standard TSO commands to apply the changes. You can extend the REXX execs to support other object types and events. The REXX execs have secure access to the original XDS command data using the IDMGETV command. IDMGETV accesses z/OS name/token callable services and places the data in REXX variables.

1.1.3 Driver Shim Started Task

The driver shim runs as a started task. Only one system that shares the security system database runs the driver shim started task. The driver shim started task must be started as part of your normal z/OS system initialization procedure and stopped during normal system shutdown.

1.1.4 LDXSERV Command

LDXSERV is an APF-authorized TSO command that provides services for the driver shim. The Subscriber channel calls LDXSERV with the NOTSSLOG parameter at startup. This uses z/OS name/token callable services to create a token in the address space. If the security system exit routines find the token, they do not generate events. This prevents publication of events for actions taken by the Subscriber (loopback).

You can use the LDXSERV STATUS command to display information about the Publisher channel event subsystem. To use the LDXSERV command, you must include the driver load library in the logon procedure STEPLIB concatenation.

1.1.5 Scriptable Framework

The interface between the security system and the driver shim uses customizable REXX execs. You can extend the execs that are provided with the driver to support other applications and databases.

Several utility execs and helper commands are provided with the driver to enable communication with the driver shim and the change log. An extensible connected system schema file allows you to add your own objects and attributes to those already supported by the driver.

For more information about the REXX execs and the scriptable framework, see Section 6.1, The Scriptable Framework.

1.1.6 Schema File

The configuration of class and attribute definitions for the connected system is specified using the schema file. You can modify and extend this file to include new objects and attributes. For details about configuring the schema file, see Section 6.2, The Connected System Schema File.

The driver uses the keywords and functions of the Top Secret TSS administrative command to define the schema. The schema includes two classes: USER and GROUP. These correspond to Top Secret users and groups.

Some items in the schema refer to keywords used to create and modify Top Secret users, but cannot be queried or synchronized. These attributes can be used only by Identity Manager policies to make event-time decisions that affect the behavior of the TSS administrative command. The auxiliary schema used to extend eDirectory™ does not include these attributes.

The schema contains some attributes that consolidate multiple Top Secret attributes.

1.1.7 Include/Exclude File

The include/exclude file allows local system policies to enforce which objects are included or excluded from provisioning by the Subscriber channel. This allows for administrative rules to be set and enforced locally rather than having processing decisions made by the Metadirectory engine. For details about using the include/exclude file, see Section 6.3, The Connected System Include/Exclude File.

To control which objects are processed by the Publisher channel, use policies. For details about customizing policies, see the Policy Builder and Driver Customization Guide on the Identity Manager 3.6.1 Documentation Web site.