Platform Services for z/OS consists of three major components.
Platform Services Process: The Platform Services Process, known in z/OS as ASCLIENT, receives requests from other z/OS address spaces and manages communications with one or more Core Drivers for Authentication Services.
System Intercept: The System Intercept is implemented in z/OS as security system exits. These exits communicate with ASCLIENT for password verification and password changes.
Platform Receiver: The Platform Receiver, known in z/OS as PLATRCVR, requests provisioning events from Event Journal Services and runs a Receiver script to carry out the appropriate action for each event as it is received.
The z/OS Platform Services Samples Library (SAMPLIB) contains sample JCL and configuration members that are useful for installing and running Platform Services. Comments in the individual members describe their function and how they should be customized for your installation. Member $CONTENT describes the contents.
For information about setting up your z/OS Platform Services Samples Library, see Section 11.3, Obtaining Platform Services for z/OS Files.
The z/OS Platform Services Load Library contains the executable programs and related files for Platform Services.
z/OS Platform Services uses several z/OS services that require APF authorization and manages a small amount of storage in z/OS ECSA that requires a system key. Therefore, the Platform Services Load Library must be APF-authorized. We recommend that you do not add this library to your linklist. The load library can be cataloged in any catalog in the normal z/OS catalog search order.
For information about setting up your z/OS Platform Services Load Library, see Section 11.3, Obtaining Platform Services for z/OS Files.
The Platform Services Process for z/OS provides an interface between the native security system on an z/OS system and one or more Core Drivers for Authentication Services. This interface is transparent to end users and applications. The only difference visible to users is that passwords are consistent across z/OS and other systems that use Identity Manager Fan-Out driver Platform Services.
The Platform Services Process is called whenever a user attempts to enter the system using a user ID and password, or when a user attempts to change the password. Such a request is redirected from the security system (RACF*, CA-ACF2*, or CA-Top Secret*) through an installation exit to the Platform Services Process, which then communicates with a Core Driver and returns a response.
If no Core Driver can be reached, or if the Platform Services Process is not running, the user's password is verified locally against the native security system database. In this case, password changes are disallowed, because the Core Driver cannot be instructed to change the user's password in eDirectory™. To ensure that the user can log on with the existing (perhaps expired) password, the password's expiration date is extended temporarily and is reset to its true value from eDirectory during a later authentication when a Core Driver can be reached.
If a password check or change is successful, the contents of the native security system database are updated to reflect the validated or new password. This allows the user to log on using the last password that worked on a z/OS system if the driver, eDirectory, or the network is not available.
The z/OS Platform Services Process is implemented as a started task. This started task, usually named ASCLIENT, performs the following tasks:
Handles all password check and password change requests from users logging on to the z/OS system
Communicates with the Core Drivers for Authentication Services
Redirects requests to other Core Drivers if a Core Driver is unreachable or returns an unexpected error
Provides the AS Client API for the z/OS system
Gathers and logs performance statistics
ASCLIENT communicates with Core Drivers using DES encryption.
Member ASCLIENT of the SAMPLIB data set contains sample JCL for the Platform Services Process. Copy this member to SYS1.PROCLIB or its equivalent, and customize it to match your z/OS Platform Load Library and z/OS Platform Configuration Member library data set names.
Start ASCLIENT during z/OS startup and stop ASCLIENT during z/OS shutdown. Because Platform Services uses the native security system to authenticate users if ASCLIENT is unavailable, ASCLIENT can be shut down and restarted if necessary without disrupting normal authentication. Password changes are disabled while ASCLIENT is not active.
ASCLIENT reads its configuration information from a PDS allocated to ddname ASCPARMS. ASCLIENT can update its configuration without a restart. For further information, see ASCLIENT Operation and Section III, Platform Services Planning.
ASCLIENT logs transactions and other messages to ddname ASCLOG. If ddname ASCLOG is not defined in the ASCLIENT started procedure JCL, ASCLIENT dynamically allocates ASCLOG as SYSOUT=*, which uses the default MSGCLASS for started tasks. If ddname ASCLOG exists in the ASCLIENT procedure, ASCLIENT uses the existing DD statement. If ASCLOG is dynamically allocated, you can use the LOGSWITCH command to close the log file and start a new one. For details about the LOGSWITCH command, see ASCLIENT Operation.
If the Platform Services Process is installed and started but the security system exits are not installed, ASCLIENT is not called for user logons and other authentications, but can be tested using ASCTEST to ensure that it is configured properly. For details about using ASCTEST, see Section 11.4, The ASCTEST Command.
The System Intercept is implemented in z/OS as RACF, CA-ACF2, or CA-Top Secret exits. These exits communicate with ASCLIENT for password verification and password changes.
The z/OS Platform Receiver is implemented as a started task that runs under the TSO terminal monitor program. It calls REXX execs that add, modify, or delete users or groups. If configured to do so, the z/OS Platform Receiver replicates password change information from eDirectory into the local security system. For details about password replication for z/OS, see Section 12.3, Password Replication for z/OS.
Member PLATRCVR of the SAMPLIB data set contains sample JCL for the Platform Receiver. Copy this member to SYS1.PROCLIB or its equivalent, and customize it to match your z/OS Platform Load Library and Receiver script data set names.
The Platform Receiver communicates with Event Journal Services using Secure Sockets Layer (SSL).
Start and stop PLATRCVR on a schedule that is appropriate for your requirements. For details about Platform Receiver operation, see Section III, Platform Services Planning.
By default, PLATRCVR reads its configuration information from the sequential file allocated to ddname ASAMCONF. You can use a JCL EXEC statement PARM to specify another source.
PLATRCVR processes events and logs the event status to the Core Driver. Log entries can be viewed using the Web interface. Receiver script messages issued by the REXX SAY verb appear in ddname SYSTSPRT of the PLATRCVR started procedure. If external programs are called by Platform Receiver scripts, their output appears under the ddname or file name that they normally write to.
Receiver and helper scripts for the z/OS Platform are implemented using REXX execs. The Platform Services installation process stores the base scripts in the library that you specify. PLATRCVR accesses these scripts through ddname SYSPROC.
The base scripts contain detailed descriptions about their operations. The scripts provided are fully functional, although they require at least minimal customization to work in your environment.
For more information about Receiver scripts, see Section III, Platform Services Planning and the scripts themselves.
Table 11-1 Receiver Scripts
Table 11-2 Helper Scripts
The z/OS script library also contains execs that you might find useful during installation and while you are developing your extensions to the base scripts.
Table 11-3 Useful Executables