Multi-tenancy overview for
VMware Aria Suite Lifecycle
products

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
    VMware Aria 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
    ,
    VMware Aria Automation
    and other products. The admin creates and manages all the tenants and associates products with tenants. The
    VMware Aria Suite Lifecycle
    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.
  • VMware Aria Automation
    Organization and Organization Owner - In
    VMware Aria 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
    VMware Aria Automation
    Organization or tenant. While adding tenants and associating
    VMware Aria Automation
    with the newly added tenant, the
    VMware Workspace ONE Access
    tenant admin becomes the organization owner for the new tenant. For more information on adding tenants, see Add tenants.
  • 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.
Multi-Tenancy Model
Shows how Aria Suite Lifecycle supports multi-tenancy