Use Tivoli Directory Integrator to build a user registry
IBM Tivoli Directory Integrator synchronizes identity data residing in directories, databases, collaborative systems, and other corporate applications. By serving as a flexible, synchronization layer between a company's identity structure and the application sources of identity data, it eliminates the need for a centralized datastore.
For more information, go to the IBM Tivoli Directory Integrator web site.
Within the context of IBM WebSphere Portal, Tivoli Directory Integrator can monitor a number of data sources, including (but not limited to) LDAP servers of various brands and databases with nearly any schema. Then, through configured "assembly lines", Tivoli Directory Integrator combines the information from those data sources into a single output server that can be used as an LDAP server by IBM WAS and WebSphere Portal. The conceptual representation of the Tivoli Directory Integrator function is depicted in the following graphic.
In this way, Tivoli Directory Integrator builds a directory that "shadows" the input data sources. Once the Tivoli Directory Integrator assembly lines are correctly configured, Tivoli Directory Integrator can monitor the data source to reflect updates in near-real time.
The LDAP server built by Tivoli Directory Integrator requires no ongoing administration to stay synchronized with the input data sources.
Example uses
- Tivoli Directory Integrator can be set up to represent an existing database with user information as an LDAP server (by creating an LDAP server with the LDAP-equivalent content of the database). In some cases, this can be easier and faster than coding your own custom User Registry implementation under WebSphere Application Server and custom MemberRepository implementation under WebSphere Portal to use the user database directly.
- Because both WebSphere Application Server and WebSphere Portal support only a single directory, Tivoli Directory Integrator can be used to allow WebSphere Application Server and WebSphere Portal to respond to users that are spread across different master directories. Tivoli Directory Integrator can "merge" the master directories, much like a virtual directory model, but with all the performance of a real directory.
- The "assembly lines" used by Tivoli Directory Integrator can take user attributes or other information that may be spread across the different data sources and compute, a new set of static group memberships for the users in the output LDAP which can then be used by WebSphere Portal for access control. This method of computing static group memberships affords you the efficiency and responsiveness of static groups in LDAP combined with the flexibility of code-based group determination, which is more flexible and much faster than LDAP-filter-based "dynamic groups".
Limitations
- If the data sources (LDAP servers or databases) use one-way encryption of passwords, it will not be possible to retrieve those passwords and store them in the output LDAP server for the shadowed user objects. This means that WebSphere Application Server and WebSphere Portal will not be able to authenticate directly against that registry. In some cases this can overcome by using an external security server (a security server external to WebSphere Application Server and WebSphere Portal) and a Trust Association Interceptor within WebSphere Application Server to accept the authentication done by the external security server. This presumes the external security server would be able to handle multiple user stores simultaneously, and authenticates against the original directories, and that the TAI would be able to represent the asserted identity to WebSphere Application Server in terms of the entries in the output LDAP server built by Tivoli Directory Integrator.
Key consideration
The LDAP directory built by Tivoli Directory Integrator for use by WebSphere Application Server and WebSphere Portal must in fact be usable by WebSphere Application Server and WebSphere Portal. This means that only the merged LDAP directory built by Tivoli Directory Integrator should have a homogenous objectclass set for all the user objects. (In this case, homogenous means no matter if two source directories have different user objectclass sets, the corresponding LDAP user objects built by Tivoli Directory Integrator should have a common objectclass set. It does not have to be the inetOrgPerson objectclass, but it has to be consistent or at least have some common bases classes across all the user objects.
Similarly, the group objects in the output LDAP built by Tivoli Directory Integrator should have a single homogenous objectclass set. The Directory Information Tree (DIT) layout of the output LDAP built by Tivoli Directory Integrator should be designed with the knowledge of how the base DNs in WebSphere Application Server and WebSphere Portal work, especially that WebSphere Application Server can only be configured with a single base DN. All users that must be authenticated by WebSphere Application Server (and thus are able to log on to WebSphere Portal ) need to be "under" this base DN.
For example, in the output LDAP built by Tivoli Directory Integrator, if the users from the various data source directories are created under different organizational units in the Directory Information Tree (ou=sourcedir1 versus ou=sourcedir2) then the base DN for WebSphere Application Server will have to be set to be the parent of these ou objects.
Related information
Parent Topic
Additional LDAP configuration