Portal Express, Version 6.0
Operating systems: i5/OS, Linux, Windows
Use Tivoli Directory Integrator to build a user registry
IBM Tivoli Directory Integrator (TDI) 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 TDI web site.
Within the context of IBM WebSphere Portal, TDI 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", TDI combines the information from those data sources into a single output server that can be used as an LDAP server by IBM WebSphere Application Server and portal.
In this way, TDI builds a directory that "shadows" the input data sources. Once the TDI assembly lines are correctly configured, TDI can monitor the data source to reflect updates in near-real time.
The LDAP server built by TDI requires no ongoing administration to stay synchronized with the input data sources.
Example uses
- TDI 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 a custom User Registry implementation under WebSphere Application Server and custom MemberRepository implementation under portal to use the user database directly.
- Because both WebSphere Application Server and portal support only a single directory, TDI can be used to allow WebSphere Application Server and portal to respond to users that are spread across different master directories. TDI can "merge" the master directories, much like a virtual directory model, but with all the performance of a real directory.
- Assembly Lines used by TDI can take attributes from different data sources and compute a new set of static group memberships for the users in the portal LDAP. These groups can be used by 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 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 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 TDI.
Key consideration
The LDAP directory built by TDI for use by WebSphere Application Server and portal must in fact be usable by WebSphere Application Server and portal. This means that only the merged LDAP directory built by TDI 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 TDI 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 TDI should have a single homogenous objectclass set. The Directory Information Tree (DIT) layout of the output LDAP built by TDI should be designed with the knowledge of how the base DNs in WebSphere Application Server and 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 portal) need to be "under" this base DN.
For example, in the output LDAP built by TDI, 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