There are major differences in the way information is organized and processed between eDirectory and RACF.
For example, there is not a one-to-one correspondence between the eDirectory and RACF representations of users, groups, and group membership.
In eDirectory, users are represented by User objects. Groups are represented by Group objects. User objects have a Group Membership attribute that lists the groups the user belongs to. Group objects have a Member attribute that includes the users that belong to it. When a user is added to a group, both objects are modified.
In RACF, users are represented by a user profile. Groups are represented by a group profile. Users and groups are associated by a connect profile. User profiles do not contain a list of the groups the user belongs to. Ordinary groups contain a list of all of their members, but universal groups do not.
This disparity places requirements on the way the driver processes events for users and groups. For example, when a user is added to a group in eDirectory, a RACF CONNECT command must be issued to perform the equivalent change in RACF.
RACF connect profiles have attributes that have no direct counterpart in eDirectory. These attributes control some of the privileges a user has when connected to the group. For example, a user can be designated as a security auditor for the group.
The z/OS RACF driver specifies a default set of attributes when creating connect profiles. You can change the way that connect profiles are created by modifying the Output transformation.
While eDirectory is hierarchical, RACF is flat—there is no concept of a move function. RACF provides no rename function. The Subscriber channel rejects move and rename commands. The sample Subscriber Event policy vetoes move and rename events. You can change this policy to perform installation-specific processing of move or rename events if required.
RACF does not perform any implicit cleanup activity when user profiles or group profiles are deleted. RACF installations typically perform special cleanup processing periodically to remove users and groups that are no longer used. The sample Subscriber Event policy vetoes delete group events and converts delete user events into a RACF revoke. You can modify these actions as appropriate for your installation.
Much of the processing in the sample Input and Output policies provided with the z/OS RACF driver deals with converting commands and events between their eDirectory representation and their RACF representation.
You can change the behavior and decisions of Identity Manager by modifying the policies and filters. For more information about changing the behavior of Identity Manager, see Section 3.0, Customizing the Driver.
An overview of z/OS RACF driver processing for various commands and events follows this topic.
IMPORTANT:Because not all mapped attributes correspond precisely, changes made in eDirectory or RACF cannot always be sent round trip through the driver and return unchanged. Furthermore, certain RACF behavior places limitations on the faithful correspondence of processing between RACF and eDirectory. For more information, see Section A.3, Driver Processing of Attributes and Commands.