This section describes multi-tenancy concepts and terminology.

  • Tenant - It is the highest level in an organizational structure in VMware Workspace ONE Access. All objects like directories, users, groups, third party IDPs are maintained individually for each tenant. Each tenant is isolated from the rest of the tenants and they do not share any resource with each other.
  • Primary Tenant - There is always at least one tenant (primary, default or base) present in the VMware Workspace ONE Access which is called as primary tenant.

    For vRealize Automation users, the primary tenant name is formed based on the first VMware Workspace ONE Access node that get is deployed and bootstrapped. For example, if idm1.vmwlab.local is the first VMware Workspace ONE Access node deployed, when you bootstrap VMware Workspace ONE Access, the primary tenant is created with name idm1. Nodes that are scaled out, such as idm2.vmwlab.local and idm3.vmwlab.local are not affected. The primary tenant name is formed only once and remains the same in a single or clustered instance.

  • Primary Tenant Alias - You cannot create sub tenants in VMware Workspace ONE Access under the primary tenant until specific configurations are set and enabled. Setting an alias name for the primary tenant is required. You must create an alias on the primary tenant. The primary tenant should be accessed through the primary tenant alias FQDN on a single node or a clustered instance.
  • Provider Admin - An admin who owns the management infrastructure, that includes VMware Workspace ONE Access, vRealize Automation and other products. The admin creates and manages all the tenants and associates products with tenants. The vRealize Suite Lifecycle Manager admin user, admin@local is the only provider admin and is authorized to perform tenant management functionalities.
  • Tenant Admin - An admin with the highest level of administrative permission in each VMware Workspace ONE Access tenant. This permission can be assigned to both local VMware Workspace ONE Access users and Active Directory users present within the VMware Workspace ONE Access tenant.
  • Tenant Aware Products - Products that support multi-tenancy and maintains proper isolation with each logical tenant instance are tenant aware products. They have one to one mapping with VMware Workspace ONE Access tenants.
  • vRealize Automation Organization and Organization Owner - In vRealize Automation, organization is the top-level construct and it maps 1:1 with VMware Workspace ONE Access tenant. Organization Owner has administrative permission in the vRealize Automation Organization or tenant. While adding tenants and associating vRealize Automation with the newly added tenant, the VMware Workspace ONE Access tenant admin becomes the organization owner for the new tenant.
  • Directory - Directories are second level of objects in VMware Workspace ONE Access. It represents an external identity store or provider like Active Directory (AD) or an OpenLDAP server. There are multiple variants of directory supported in VMware Workspace ONE Access. You can add Active Directory Over LDAP and Active Directory with IWA in the Directory Management section.
  • Directory Synchronization - While adding directories, configuration options are provided to filter and synchronize the required users and groups from the identity store or provider to the VMware Workspace ONE Access database. Only after a successful sync, you can integrate the users and groups with VMware Workspace ONE Access.
  • Directories in tenant - Each tenant can contain several directories. The same directory configuration can be present in multiple tenants, however, it is considered a separate directory. For example: You have added Directory A in primary tenant with some directory configurations (User DNs, Group DNs, Sync configurations). And you have two sub-tenants named Tenant-1 and Tenant-2. The same directory configurations of directory A can be used on to add directories A1 and A2 on each of the sub-tenants respectively, so that the same set of users and groups are synced in sub-tenants - Tenant-1 and Tenant-2. After adding, any changes to the sync configurations of directory A in primary tenant will not affect directories A1 and A2 and its synced users and groups in Tenant-1 and Tenant-2. All three directories and its configurations are independent of each other. All three directories are affected only if the external identity store or provider changes. For example, if users or groups are getting removed directly from the Identity provider then it influences all three directories in all three tenants.
Figure 1. Multi-Tenancy Model