User Registry And Member Repository - IBM BS029ML - WebSphere Portal Server Self Help Manual

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 extId
, or . 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

user registry
In the context of WebSphere Application Server, a 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).
member repository
In the context of WebSphere Portal and Member Manager, a 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.
89
Chapter 4. WebSphere Portal security