Most of our customers use single-tenant authentication. If your company wants to set up different tenants for different teams, VMware Aria Operations for Applications (formerly known as Tanzu Observability by Wavefront) supports multi-tenancy.
Several of our customers have asked for an environment that supports separate tenants for different teams. For example, here at VMware it made sense to keep the VMware vSphere team separate from the VMware NSX team – both teams use Operations for Applications. This separation of teams, called multi-tenancy, works like this:
- The administrator at the customer site requests tenants from our Technical Support team and provides the tenant administrator emails and other information such as the IdP.
- After our Technical Support team has set up the tenants, each tenant administrator (a Super Admin or a user with the Accounts permission) invites users to that tenant.
- A Super Admin or a user with the Accounts permission can invite users to multiple tenants.
- After logging in to the service instance, users who have been invited to multiple tenants:
- Are directed to the last tenant they used.
- Can switch to other tenants from the gear icon on the toolbar without having to log in again.
Multi-tenancy must be set up in collaboration with our Technical Support team, as discussed next.
How to Set Up Multi-Tenancy
Multi-tenancy is set up jointly by the administrator at the customer site and our Technical Support team:
- The administrator decides on the multi-tenancy mode (see below), that is, sandbox or strict multi-tenant mode.
- The administrator requests a multi-tenant setup from our Technical Support team, providing the following information:
- Names of the tenants to create (one tenant per team).
- Email addresses of the administrators of each team.
- IdP details.
- Sandbox mode or strict mode (see below).
- Our Technical Support team sets up the multi-tenant environment based on the request:
- Enables multi-tenancy for the customer.
- Creates a tenant for each team specified by the customer.
- Points each tenant to the customer’s IdP.
- Creates tenant administrator users with the Accounts permission on each tenant.
- The administrator at the customer site and the newly specified tenant administrator users with the Accounts permission can then:
Administrators who request a multi-tenant setup can specify sandbox mode or strict mode.
Sandbox Mode (Default Login Enabled)
In sandbox mode, any user who is authenticated by the corporate ID provider is given access to a default tenant.
- If the user was never invited to any of the tenants, we create a user on the default tenant.
- If the user has been invited to an existing tenant, the user is given access to that tenant, and we do not create a user on the default tenant.
Strict Mode (Default Login Disabled)
In strict mode, users can access the environment only if they’ve been invited to one or more of the tenants.
How Users Experience Multi-Tenant SSO
If your environment is set up to support multi-tenant SSO, you log in to your service instance with your SSO credentials. After successful authentication, your user experience is like this:
- If you’ve been invited to only one tenant, then you are logged in to that tenant after authentication.
- If you’ve been invited to more than one tenant, you are logged in to the last tenant you logged in. You can switch to the other tenants by selecting the tenant from the gear icon on the toolbar.
For each tenant, you have specific permissions. That means, for example, if you have the Accounts permission on Tenant A, you don’t necessarily have that permission for Tenant B. See permissions for details.Note: You can have different sets of permissions on different tenants because each tenant administrator controls the permissions for that tenant for each user.
- When you log out, the logout applies to all tenants.
Point a Proxy to a Different Tenant in a Multi-Tenant Environment
If you are an administrator in a multi-tenant environment, you sometimes have to point your proxy or proxies to a different tenant. Follow these steps:
- Delete the
.wavefront_idfile. The precise name of the file might differ. It’s
/usr/local/etc/wavefront/wavefront-proxy/.wavefront_idin a Mac environment with no customizations.
- Restart the Wavefront proxy.