Handling Delayed Delete Requests

The Connector’s utility CTSC100 and IdentityIQ’s Delay parameter work together to provide the capability for delayed delete as illustrated in the following figure.

When the Delay parameter is used in a delete request, IdentityIQ instructs Connector not to perform the delete request immediately, but to queue it for delayed processing [1].

The delete request is written to Connector dataset <prefix>.<version>.RCFDELRQ [2] and the user is revoked [3]. This ensures that the user is denied access until actually deleted.

When utility CTSC100 is run [4], it processes the request dataset and activates IRRUT100 once [5] to process all the requests specified in the dataset. CTSC100 processes IRRUT100 output and creates a REXX exec dataset with cleanup commands for each of the requests [6]. The dataset contains RACF commands to delete all occurrences of the user or group.

CTSC100 then optionally executes all of the cleanup REXX exec datasets [7] and deletes the users or groups that were processed [8].

If the utility is not used to execute the cleanup, the administrator is responsible for manually executing the cleanup commands in the REXX exec dataset.

This procedure must be executed periodically to handle the delayed delete requests. Member CTSC100 in the Connector JCL library is a sample job which activates this procedure.