IBM BS029ML Self Help Guide - Page 103

When an application, such as WebSphere Portal, uses Member Manager, the application may have its own application-specific repository for data that is related to the member in Member Manager. This means the application needs a linkage for the data of a member managed by Member Manager and its own application-specific data for the same member. Since the memberDN may be changed and reused, in general it is not suitable to be used as the linkage. However, memberUniqueId, which is unique, static, and never reused, is suitable to be used as the linkage. Still, with the previous example, the memberDN of "Jane Doe" was changed, but her application data should be still linked by the memberUniqueId. Thus, this is why memberUniqueId is recommended to be static and never changed. If this "Jane Doe" leaves the company and a new "Jane Doe" joins the same company, the second "Jane Doe" may have the same memberDN, but she would not be able to access the application data in the system, because the memberUniqueId is different. In the context of WebSphere Portal, only two member types, Person and Group, are supported. In WebSphere Portal, the member unique identifier (memberUniqueId) is called external ID, or extId. In Version 6 of WebSphere Portal, Portal Access Control (PAC) utilizes extId as the primary key in permission database tables, linking the users and groups to the access control data. 4.1.3 User registry and member repository In the context of WebSphere Application Server, a user registry stores all user and group data, including the user login ID and password, other user and group attributes, user and group membership information, and so on. In the context of WebSphere Application Server global security, three user registry types are supported. They are the Local Operating System user registry, Lightweight Directory Access Protocol (LDAP) user registry, and custom user registry (CUR). In some corporations, the existing directory servers, such as LDAP servers, are not capable of handling their needs. For example, a recent merger of two companies cannot consolidate their employees into a single directory in a short period. They may have to run their businesses to accommodate the two coexisting sub-directory server systems. In this case, WebSphere Application Server provides an Application Programming Interface (API) for customers to develop their own custom user registry (CUR). They can also consider other solutions, such as Tivoli Directory Integrator, to provide integration of their multiple directory systems. Within WebSphere Portal, only LDAP and custom user registries are supported, not the Local Operating System, because of the configuration of the Lightweight Third-Party Authentication (LTPA) mechanism used in Single Sign-On (SSO). In the context of WebSphere Portal and Member Manager, a member repository is the store for user profile data and the group data, and their membership information. Two different terms (user registry and member repository) are used because it is possible for the datastores to be different. For example, when the portal server requires application specific user attributes that are not available in the LDAP server, the administrator can opt to use the LookAside mechanism provided by WebSphere Member Manager. Thus, the member repository has the extension in the LookAside database tables. In most cases, however, the user registry and member repository are in the same datastores. WMM supports three types of member repositories: database (DB), LDAP, and custom member repository (CMR). In the database member repository (WMMUR DB), WMM had provided its own Custom User Registry (CUR) implementation (using the CUR API provided by WebSphere Application Server) to be used in the application server security configuration. Chapter 4. WebSphere Portal security 89