HCD LDAP backend: Structure and mode of operation

The HCD LDAP backend is plugged into the IBM Tivoli Directory Server for z/OS. It is configured using the IBM Tivoli Directory Server for z/OS configuration file (typically called ds.conf).

The HCD LDAP backend is similar to the RACF backend SDBM. As with SDBM, the main function of the HCD LDAP backend is to mediate between the IBM Tivoli Directory Server for z/OS and an external component, in this case HCD. HCD retains control over the IODFs; update requests are validated, processed, and the results stored by HCD in the appropriate IODF. Since it is HCD that processes the requests, updates through the IBM Tivoli Directory Server for z/OS preserve the integrity of the IODFs.

Thus, the HCD portion of the DIT must reflect the data structure of HCD exactly. For this reason, rather strict rules (as compared to the DB2 backend TDBM) have to be observed when requesting an update of IODF data through the IBM Tivoli Directory Server for z/OS.

Access control to the HCD LDAP backend is based on RACF permissions for user IDs, not (as is the usual practice) on LDAP Access Control Lists (ACLs). The HCD LDAP backend performs all services on behalf of a user ID. It accepts a service request only on condition that the associated user ID has previously been bound to (authenticated by) SDBM. If this condition is fulfilled, the HCD LDAP backend switches to this user ID and tries to perform the request using only the RACF access rights granted to the user ID in question. In this way, access to IODFs through the LDAP interface and through the ISPF interface are both controlled by the same security mechanism. Note that this will have some consequences for the configuration of the IBM Tivoli Directory Server for z/OS.

The HCD LDAP backend uses several instances of HCD to perform operations on IODFs. Each of these instances serves exactly one request at a time on behalf of a user ID. This strategy provides an easy method of handling the validation of modified configuration data and serialization of client requests. The HCD instances are managed according to the following principles:

1. After starting up, the HCD LDAP backend opens a (configurable) minimum number of address spaces each of which contains exactly one HCD instance for handling requests. The minimum number of address spaces is controlled by the configuration file parameter MinHcdInstances (see Configuration file parameters).
2. When the HCD LDAP backend receives a legitimate request on behalf of a user ID, it assigns this request to an HCD instance. This instance is then tied to the user in question, that is, all subsequent requests from this user will be routed to this same HCD instance.
3. If the number of available instances is not sufficient, the HCD LDAP backend will open a new instance provided that a (configurable) maximum number of instances is not exceeded. The maximum number of address spaces is controlled by the configuration file parameter MaxHcdInstances (see Configuration file parameters).
4. In order that instances tied to a user can be switched to another user after having been idle for a certain time, two (configurable) timeout values can be defined:
   • The lower value specifies the time after which an instance can be switched to a user who requests a service and has not yet been tied to an HCD instance. The lower timeout value is controlled by the configuration file parameter AllowSwitchTime (see Configuration file parameters).
   • The higher value specifies the time after which the connection between an HCD instance and a user is dissolved in any case. The higher timeout value is controlled by the configuration file parameter ForceSwitchTime (see Configuration file parameters).

   The lower value provides additional flexibility: As long as there is no need to switch to a new user, the current connection can be maintained until the second timeout is reached.

A special feature of the HCD LDAP backend is that it supports transactions. A transaction is a sequence of requests which is only executed as a whole. If one of the individual requests fails, the whole transaction is not carried out. This provides additional protection against inconsistency of data. Note, however, that transactions are only supported in conjunction with LDAP V3, not with LDAP V2.