Virtual member manager hierarchy is designed to ease the
integration with LDAP directories, particularly directories with existing
data.
Every LDAP directory has a Directory Information Tree (DIT), which
is a hierarchical structuring of entries on the LDAP server. Every
entry in an LDAP server occupies a location in the DIT and the distinguished
name (DN) of an LDAP entry identifies the location of the entry in
the DIT.
Because virtual member manager needs to use existing LDAP directories
(both read from and write to them), the virtual member manager hierarchy
is a hierarchical structuring of entities. This hierarchical structure,
as much as possible, reflects the LDAP DIT structure. This enables
virtual member manager to use various operations, such as create,
to place an entry into an LDAP directory and respect the existing
DIT structure that is already in place.
Virtual member manager hierarchical structure also provides virtual
member manager with a hierarchical namespace. Adopting ideas from
LDAP directories, each name in the virtual member manager hierarchical
namespace follows the same format as an LDAP DN. In virtual member
manager, the DNs are referred to as uniqueNames. Each uniqueName
uniquely identifies an entity in virtual member manager, but a uniqueName
is not static (it can change) and it may be reused. As a result,
a uniqueName only uniquely identifies an entry at a point in time,
not over time.
When virtual member manager is used with multiple repositories
simultaneously, the virtual member manager hierarchy is divided among
the multiple repositories so that uniqueNames for the different repositories
do not collide.
As an example, virtual member manager is configured with three
repositories, two of which are LDAP and one is a database. The LDAP
directories have the DIT structures shown in the diagram. The corresponding
virtual member manager hierarchy is also displayed in the diagram:
Figure 1. Virtual member manager hierarchy
The top of the virtual member manager hierarchy is an imaginary
root, that is not illustrated. Entries under the root are mapped
to one or more main repositories.
Note: A property extension repository
is not considered a main repository.
Entries from a main repository
reside under the corresponding entries assigned to the repository.
If a repository does not have an explicit structure (like the LDAP
DIT), it is the responsibility of the repository adapter to do any
transformation necessary. For example, the database repository in
the diagram might have a flat namespace (for example, its entries
have primary keys from 1-100). The database repository adapter is
responsible for translating a virtual member manager uniqueName into
a primary key that the database can understand.
Virtual member manager provides a construct called a realm which
consists of all or a subset of the entries from a main repository
under a partition of the virtual member manager hierarchy. Using
the previous example, dc=comA,dc=com is considered a realm.
When an entry is to be created by virtual member manager, the caller
can optionally specify a parent entry in the virtual member manager
hierarchy under which the new entry are created. If a parent entry
is not specified, a default parent (which is configurable for each
realm ) is used. In virtual member manager a default parent entry
can be configured for each entity type within each realm.
Entries in the virtual member manager hierarchy under the imaginary
root can be defined during configuration time and can also be created
programmatically at runtime.
Note: The entries might not correspond
to real entries in the profile repositories. For example, the entry
o=comC in the hierarchy might not correspond to a real entry in the
profile repository for company C.
The illustrated scheme implies that if multiple repositories have
entries with the same name (for example, two different LDAP directories
each with an entry named o=USdiv ) and the customer wants to configure
those entries directly under the root in the virtual member manager
hierarchy, those entries must be changed to have unique names. For
example, one of the LDAP directories with the o=USdiv entry can map
that entry to the o=USdiv entry in the virtual member manager hierarchy.
But the other directory with the o=USdiv entry must map to an entry
with a name like o=USdivision in the virtual member manager hierarchy.
Note: o=USdivision
is a uniqueName configured in virtual member manager, it is not stored
in the LDAP directory as a real entry.
If virtual member manager is configured with only one repository,
that repository occupies the entire the virtual member manager hierarchy.
To take advantage of the potentially globally-unique nature of
LDAP DNs (for those that follow RFC 2247, by making use of Internet
Domain Names), virtual member manager supports dc=com as part of a
virtual member manager uniqueName (even if dc=com does not identify
an entry in virtual member manager).
The virtual member manager hierarchy is to virtual member manager
as the DIT is to LDAP. However, some important points to remember
are:
- Virtual member manager hierarchy might look exactly the same as
an LDAP DIT, but the virtual member manager hierarchy is not the LDAP
DIT. It is mapped onto the LDAP DIT and, as such the uniqueName
in virtual member manager, although it looks very much like an LDAP
DN, it is not an LDAP DN. Virtual member manager uniqueName is not
guaranteed to be the same as the LDAP DN, even if the two happens
to have the same value for some deployments of virtual member manager.
- Virtual member manager hierarchy affects the location of an entry
when it is stored, that is which repository is used, if multiple main
repositories are configured under virtual member manager. It also
affects the actual location of the entry in the repository (as determined
by the repository adapter).
- Virtual member manager hierarchy is not meant to reflect a meaningful
organizational structure even if it happens to look like a meaningful
organizational structure for some deployments. There can be quite
a number of different organizational structures for a virtual member
manager deployment. For example, a company might organize its entities
according to a functional reporting structure, and might also organize
its entities according to a regional reporting structure. Another
might organize the entities for the purpose of performing delegated
administration. Because of the need for different organizational
structures, the virtual member manager hierarchy can only be a meaningful
organizational structure for a single organizational structure. With
multiple repositories and structures, virtual member manager cannot
represent a meaningful organizational structure.
- Virtual member manager hierarchy might not be uniform. Entries
placed into the virtual member manager hierarchy might not follow
a uniform approach in terms of their placement. Virtual member manager
hierarchy might place entries according to their type in one portion
of the hierarchy, and place entries according to the organization
to which they belong in another portion of the hierarchy.
- Entries in the virtual member manager hierarchy and the underlying
LDAP DIT need not map in a one-to-one manner. It is possible for
a repository adapter to do the transformation such that multiple entries
in an underlying repository are combined to become a single entry
exposed by virtual member manager, or an entry in an underlying repository
separated into multiple entries exposed by virtual member manager.
- The parent and children references on Entity refer to the parent
entry and children entries in the virtual member manager hierarchy,
not the hierarchy of the underlying repository. Virtual member manager
delegates most of the work of resolving the parent and children entries
to the appropriate repository adapter.
- LDAP supports many different DIT structures, virtual member manager
supports representative DIT structures only.