Overview

The DirX Identity domain is the entity that supports multi-tenant operation: the ability to configure and run different user populations, privilege models, rules, policies and workflows that remain completely separate from each other within a single DirX Identity installation. Users and administrators operating in a particular domain cannot view or access the data contained in a different domain.

A DirX Identity domain is composed of:

The System domain, which contains target systems.
The Provisioning domain, which contains the domain-specific user (identity) data and the Provisioning configuration data; for example, its privilege structure and its policies. This data is clearly separated between different Provisioning domains and is not accessible between them.
The Connectivity domain, which contains the system-specific data required for synchronization from source systems and to target systems, such as IP addresses and bind profiles. Each Provisioning domain is related to a Connectivity domain. You can configure a separate Connectivity domain for each Provisioning domain or you can have your Provisioning domains share a single Connectivity domain.

The System domain and the Provisioning domains form the Provisioning configuration, and reside on one directory server. The Connectivity domains form the Connectivity configuration. You can have only one Connectivity domain per directory server because of the fixed context prefix dxmC=DirXmetahub. This domain can be shared by several Provisioning domains residing on the same directory server and also on other directory servers.

The following figure illustrates the DirX Identity domain architecture.

Figure 1. DirX Identity Domain Architecture

A Provisioning domain can host one or many tenants. In a multiple-tenant configuration, each tenant has its own user data and Provisioning configuration data. The Provisioning configuration contains in particular tenant-specific access policies and object creation and approval request workflows. These items help to keep the tenant‘s data separate from other tenants. There are also Provisioning domain configuration data, which are shared by all tenants. These items include the object descriptions, event policies, attribute modification policies and delete policies. The following figure illustrates this architecture.

Figure 2. Multi-Tenant Provisioning Domain Architecture

Multi-tenancy can thus be implemented in a variety of ways:

By configuring one System domain, one Provisioning domain and one Connectivity domain on a single directory server and then duplicating this configuration on an additional directory server for each additional tenant. This configuration is described in the use case “Single Domain”.
By configuring multiple Provisioning domains that share a single Connectivity domain. This configuration is described in the use case “Multiple Provisioning Domains with a Common Connectivity Domain”.
By configuring multiple Provisioning-and-Connectivity domain pairs over several different directory servers. This configuration is described in the use case “Multiple Provisioning Domains with Separate Connectivity Domains”.
By configuring a single Provisioning domain to support multiple tenants. This configuration is described in the use case “Multiple Tenants within a Single Provisioning Domain”.

The remainder of this document provides more information about these use cases.

Use Cases

The following sections describe typical use cases that occur in customer environments. There are three basic use cases for domain configuration with a standard setup of servers and Web Center. There is another use case that shows how to configure multiple tenants within a single Provisioning domain.

Be aware that other use cases are possible that are not described in this document.

Note also that this document does not discuss distribution aspects that are not relevant in the context of this document; for example, the distribution of C++-based Servers.

Single Domain

If you run only one Provisioning domain, you can keep the System domain, the Provisioning domain and the Connectivity domain on one machine. The following figure illustrates this configuration.

Figure 3. Single Domain on One Machine

As illustrated in the figure, this use case comprises:

A single Provisioning domain (Prov. Dom.) and a related Connectivity domain (Conn. Dom.). The System domain (Syst. Dom.) is also available.
A Web Center for managing objects in the Provisioning domain.
A Java-based Server that reads and executes request workflows from the Provisioning domain and Java-based provisioning workflows from the Connectivity domain.
A C++-based Server that reads and executes Tcl-based workflows from the Connectivity domain.

This is the standard configuration that most customers use.

You can implement multi-tenancy with this use case by setting up completely separate DirX Identity installations with this domain configuration on multiple machines, one for each tenant. This configuration allows for strict separation of the data but costs more in terms of software maintenance.

Multiple Provisioning Domains with a Common Connectivity Domain

If you intend to run several Provisioning domains, you have two options: you can use a common Connectivity domain for all the Provisioning domains (this use case) or separate Connectivity domains for each Provisioning domain (the next use case).

Note that this use case assumes that all the Provisioning domains and the Connectivity domain are stored in the same directory server and that all components – directory server, Java- and C++-based Identity servers and Web Center – run on the same machine. It is also possible to have a subset of the Provisioning domains on another directory server and the associated Java-based servers and Web Center on another machine. But this is not discussed here.

Note that this use case requires a machine with enough hardware resources (processors, main memory and file storage) to handle the configuration. The following figure illustrates this use case.

Figure 4. Multiple Provisioning Domains with One Common Connectivity Configuration

This use case comprises:

Several Provisioning domains (Prov. Dom. A, B, C …) and one common Connectivity Domain (Conn. Dom.). The System domain (Syst. Dom.) is also available.
A separate Web Center for each Provisioning domain.
A separate Java-based Server for each Provisioning domain. It reads and executes request workflows from the specific Provisioning domain and Java-based workflows from the common Connectivity domain.
One C++-based Server that reads and executes Tcl-based workflows from the Connectivity domain.

Customers that host several small to mid-size Provisioning domains should use this configuration. User, role, policies and request workflows of the Provisioning domains are clearly separated. All of the provisioning workflows for these domains are kept in the common Connectivity domain but are logically separated using different folder structures.

Multiple Provisioning Domains with Separate Connectivity Domains

If each Provisioning domain needs to have its own Connectivity domain, you must distribute the Connectivity configuration data over different machines, where each one runs its own directory server. The following figure illustrates this configuration.

Figure 5. Multiple Provisioning Domains with Separate Connectivity Configurations

As illustrated in the figure, this use case comprises:

Several Provisioning domains (Prov. Dom. A, B, C …) with corresponding Connectivity domains (Conn. Dom. A, B, C, …). The System domain (Syst. Dom.) is also available.
A separate Web Center for managing objects in each Provisioning domain.
A separate Java-based Server that reads and executes request workflows from the specific Provisioning domain and Java-based workflows from the corresponding Connectivity domain.
A separate C++-based Server that reads and executes Tcl-based workflows from the relevant Connectivity domain.

In this scenario, the system domain, all Provisioning domains and the first Connectivity domain can reside on machine 1. You need an additional machine for each additional Connectivity domain.

Multiple Tenants within a Single Provisioning Domain

Customers who find that they frequently need to add new tenants to their DirX Identity installation may want to set up these tenants within a single Provisioning domain, as illustrated in Figure 2, rather than adding multiple separate Provisioning domains. The single Provisioning domain-multiple tenant use case requires less configuration effort. However, their options for specific customizations are limited, because all tenants use the same set of attributes. The customization must focus on object descriptions, especially for users. As a result, this use case does not apply to tenants that want their own data schema and further specific customizations.

This use case comprises:

A single Provisioning domain as described in the chapter "Single Domain".
Extensions to default access policies, user and privilege structures and creation workflows necessary for separating multiple tenants within a single Provisioning domain.

Note that the proposed solution for this use case requires the deployment of request workflows and thus the DirX Identity Professional Suite. See the DirX Identity data sheet and the DirX Identity Installation Guide for details.

Extensions for Scalability and Higher Throughput

Regardless of whether you run one or multiple Provisioning domains or whether you have one or more Connectivity domains, you can set up each DirX Identity domain with only one or multiple Java-based Servers and Web Centers. The following figure illustrates this concept.

Figure 6. Options for Scalability and Higher Throughput

As shown in the figure:

You can set up multiple Web Center applications on one or more Tomcat servers either to separate the applications for specific user types (end users, administrators) or to handle scalability issues.
For each Provisioning domain, you can set up and run multiple Java-based Servers. You may want to separate specific scenarios from each other - for example, interactive applications from automated background applications - or you may want to enhance performance of the total solution.

You should plan your solution thoroughly for the first setup, but you can add additional resources later on if more performance or separation of specific applications is required. For complete details about scalability and higher throughput, see the use case document High Availability.

Use Case Comparison

The following table compares the use cases described in this document to help you with your decision process.

Number of Provisioning and Connectivity Domains

This comparison evaluates the number of Provisioning and Connectivity domains that must be set up for each use case.

Table 1. Use Case Comparison - Number of Provisioning and Connectivity Domains
Criteria	Single Provisioning / Connectivity Domain	Multiple Provisioning Domains / Common Connectivity Domain	N Tenants in one Provisioning Domain / Connectivity Domain	Multiple Provisioning Domains / Separate Connectivity Domains
# Provisioning domains	1	N	1	N
# Connectivity domains	1	1	1	N
Strict separation	Yes	No	No	Yes
Moderate separation	Yes	Yes	No	Yes
Separation by access policies needed	No	No	Yes	No
# of Directory Servers	1 to 2	1 to 2	1	N - 1
Set up complexity	Low	Medium	High	High

The table presents the following evaluation criteria:

# Provisioning domains - the number of configured Provisioning domains supported by the use case.

# Connectivity domains - the number of configured Connectivity domains supported by the use case.

Strict separation – whether the use case offers strict separation of tenant data in Provisioning and Connectivity domains. This requires a single domain scenario per hosted tenant. However, this scenario multiplies the maintenance costs for the installed software and hardware.

Moderate separation – whether the tenant data in a Provisioning domain are strictly separated, but in a common Connectivity domain. Separation of Provisioning domains is sufficient if the hosted customers work only with Web Center or with Identity Manager, but in the Provisioning view group.

Separation by access policies needed – separation of tenant data within a Provisioning domain requires appropriate access policies. The workflow configuration in the Connectivity domain is in common with the “Moderate separation” criterion.

# Directory Servers - the number of installed directory servers supported by the use case. For the first two use cases, the customer can select between a common Provisioning and Connectivity database (1 server) or a distributed database (2 servers).

Set up complexity - the complexity and effort to set up and maintain the use case.

Number of Tenants in a Provisioning Domain

The following table compares the different methods for implementing multi-tenancy: within a single Provisioning domain or across multiple Provisioning domains, one for each tenant.

Table 2. Use Case Comparison: Number of Tenants per Provisioning Domain
Criteria	One Tenant per Provisioning Domain / Multiple Provisioning Domains	Multiple Tenants per Provisioning Domain
Per-tenant data schemas	Yes	No
Per-tenant customizations	Yes	Limited
# Java-based Servers	N (one additional server for each Provisioning domain)	1
Professional Suite required	No	Yes

The table presents the following evaluation criteria:

Per-tenant data schemas – whether the use case allows different tenants to have different LDAP data schemas.

Per-tenant customizations – whether the use case allows each tenant to have its own specific customizations. The “n tenants per domain” case requires common object descriptions. If tenants use the same target systems, they also share the same object descriptions (including user-to-account attribute mapping) for accounts and groups.

# Java-based Servers – the number of Java-based Servers that must be deployed.

Professional Suite required – whether the use case requires the Professional Suite version of DirX Identity to be installed.

Scalability and Throughput

For each Provisioning domain, you need to deploy at least one additional Java-based server. Thus, the main difference between the “n tenants in 1 Provisioning domain” use case and the “n Provisioning domains” use case is that you need to deploy at least 1 to n Java-based Servers.

Multiple Provisioning domains and thus multiple customers can share the same C++-based server. You can install at most one C++-based server per system.

The following use case comparison is for one Provisioning domain only.

Table 3. Use Case Comparison: Scalability and Throughput
Criteria	Distribution over Multiple Java-based Servers	Distribution with Resource Families
Distribution type	Cross Servers	Within Server
Resources used	Processes	Threads
Restart after reconfiguration	No	Yes*
Restrictions	Limited by hardware	Limited by hardware

The table presents the following evaluation criteria:

Distribution type - the distribution of messages to Java-based Servers is dynamic. The distribution of messages within a Server depends on the number of configured resource families.

Resources used – whether the use case uses separate processes or threads.

Restart after configuration – whether the use case requires a restart after configuration or re-configuration. Using Web Admin, the administrator can change the number of threads per resource family. This is valid only until the next server start. To make this number persistent, the administrator must use DirX Identity Manager. However, these changes require a re-start of the server.

Restrictions – the restrictions associated with the use case.