Express (Distributed operating systems), v8.0 > Secure applications and their environment > Authenticate users > Select a registry or repository > Manage realms in a federated repository > Virtual member manager > Component overview
Virtual member manager hierarchy
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 VMM needs to use existing LDAP directories (both read from and write to them), the VMM hierarchy is a hierarchical structuring of entities. This hierarchical structure, as much as possible, reflects the LDAP DIT structure. This enables VMM 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 VMM with a hierarchical namespace. Adopting ideas from LDAP directories, each name in the VMM hierarchical namespace follows the same format as an LDAP DN. In VMM, the DNs are referred to as uniqueNames. Each uniqueName uniquely identifies an entity in VMM, 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 VMM is used with multiple repositories simultaneously, the VMM hierarchy is divided among the multiple repositories so that uniqueNames for the different repositories do not collide.
As an example, VMM 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 VMM hierarchy is also displayed in the diagram:
The top of the VMM hierarchy is an imaginary root, that is not illustrated. Entries under the root are mapped to one or more main repositories.
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 VMM 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 VMM hierarchy. Using above as example, dc=comA,dc=com is considered a realm.
When an entry is to be created by VMM, the caller can optionally specify a parent entry in the VMM 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 VMM a default parent entry can be configured for each entity type within each realm.
Entries in the VMM hierarchy under the imaginary root can be defined during configuration time and can also be created programmatically at runtime.
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 VMM 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 VMM hierarchy. But the other directory with the o=USdiv entry must map to an entry with a name like o=USdivision in the VMM hierarchy.
o=USdivision is a uniqueName configured in VMM, it is not stored in the LDAP directory as a real entry.
If VMM is configured with only one repository, that repository occupies the entire the VMM 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), VMM supports dc=com as part of a VMM uniqueName (even if dc=com does not identify an entry in VMM).
The VMM hierarchy is to VMM 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 VMM hierarchy is not the LDAP DIT. It is mapped onto the LDAP DIT and, as such the uniqueName in VMM, 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 VMM.
- 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 VMM. 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 VMM 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 VMM hierarchy can only be a meaningful organizational structure for a single organizational structure. With multiple repositories and structures, VMM cannot represent a meaningful organizational structure.
- Virtual member manager hierarchy might not be uniform. Entries placed into the VMM 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 VMM 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 VMM, or an entry in an underlying repository separated into multiple entries exposed by VMM.
- The parent and children references on Entity refer to the parent entry and children entries in the VMM 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, VMM supports representative DIT structures only.
Parent topic: Component overview