vCloud Director Identity and Access Management – Part 1

(Update 4-2-2020: Rights Bundles section added)

(Update 29-3-2020: Org VDC section added)

Recently I had a meeting with a customer to discuss the possibilities within vCloud Director (vCD) to implement a suitable Identity and Access Management (IAM) solution.

IAM Solutions are imported to many customers that have teams with multiple roles that manage the service. Other reasons businesses need it could be for compliance or legislation requirements.

Wikipedia summarizes it quite good:

Identity and Access Management (IAM), is a framework of policies and technologies for ensuring that the proper people in an enterprise have the appropriate access to technology resources.

In this blog post I want to show you the possibilities vCD has built-in and when to look for external solutions that can be bolted on. The post assumes a basic understanding of vCD constructs like Orgs, Org VDC, Groups and Roles. The vCD Tenant Admin product documentation describes this very well.

In this article I use the words customer and tenant. To prevent misunderstandings, I use the term customer for a company that pays for the service. The term tenant is used to refer to companies consuming the platform.

I decided to split the topic into a multi-part series due to the length . The second part can be found using the link below:

vCloud Director Identity and Access Management – Part 2

Why do I need an IAM solution

Reasons why customers need an IAM implementation can vary but may comprise of:

• Using corporate accounts to login to vCD
  • Implemented using a one way trust relation with the customers IdP
• Implement strict password policies
• Implement Multi-Factor Authentication
• Account task separation
  • Separate between Admin and Ops type account
• Limit account span of control
  • If Org VDCs or vApps maps to a different tenant customers, a tenant might need an API user per tenant customer
• Delegation of control
  • If a tenant customer has end users that need console access for VM’s in their vApp

What’s available in the product

Before diving into other solutions, it’s important to know which features vCD has available natively:

• Local Users
• Groups
• Roles
  • Global Roles
  • Custom Global Roles
  • Tenant Roles
• Rights Bundles
• Federation
• vApps
  • Ownership
  • Sharing
• Org VDC (see part 2)

Local Users

The options in vCD for user management are brief. The basic user properties like (account) name, password, contact information and assigned role are available.

In the policies section of the vCD tenants “Administration” menu only a few password policy options are available. For most use cases the provided options are not adequate.

The password options for local users are:

When more strict password policies are needed, the solution is to federate the vCD Org with an external SAML based Identity Provider (IdP) and implement a suitable password policy within the IdP solution. More about this topic in the Federation section.

Advised usage for Local Users:

Org Admins

Limit the Org admin roles to only a few and keep those accounts safe. For daily operation use a federated account with more limited rights.

API access

If every Org VDC maps to a different tenant customer, you could use a separate local API user for every Org VDC. This way use Custom Global Roles or Tenant Roles in combination with the vApp permissions to limit the span of control for a specific account.

Groups

Only when Federation is configured (more about this topic in the Federation section) the groups section becomes available in the vCD tenant “Administration” menu. Groups configured to be federated from the IdP show up in the list. In this example the group names configured in the IdP solution have the same name as the Global Roles.

The groups can be be used to set permissions to vCD resources such as vApps and Content Libraries. Group membership changes are performed within in the IdP solution, not vCD.

Roles

Roles are most often configured by the Service Provider. In some cases it makes sense for vCD tenants to create their own roles. vCD supports 3 types of roles. All 3 types are explained below.

Global Roles

Global Roles are the default available roles provided by vCD after installation and are shared by default to every tenant. Every role has a specific set of rights. The vCD documentation describes the predefined roles and their rights.

Although it is possible, the general advice to Service Providers is not to change the rights of the default Global Roles. If there is a need for customization, create a new Custom Global Role.

Advised usage for Global Roles:

• Most frequent used roles and rights for all tenants for day to day tasks
• To provide modified roles to tenants, use new Custom Global Roles

Custom Global Roles

Customer Global Roles are available to Service Providers to create additional roles with a specific set rights. This type of role can be shared to specific or all tenants.

Advised usage for Custom Global Roles

• If the default set of roles are to limited for most tenants. For example, create a role with specific rights for network and security admins.
• Implement a new set of standardized global roles to implement separation of control for all tenants. For example, create a role to manage only Org VDC properties and not the Org itself.

Tenant Roles

Tenant Org Admins can create their own specific roles to be assigned to their users.

Advised usage for Tenant Roles

Limit usage of specific features to their users which is configured by the Org Admin.

• Tenant Org Admin wants to limit the usage of a feature to specific Org users. For example a feature that a tenant is additionally charged for.
• Tenant want to be fully in control over the assigned rights to their users.

Rights Bundles

The why and how about using Rights Bundles is lacking in the vCD product documentation. It only mentions the configuration part of it. The post on the VMware Cloud Provider blog by Jeff Morowski provides the best understanding of the matter currently. Jeff’s post is the reason I added this section to give you a full understanding of all IAM related options with vCD.

Rights Bundles and the previously mentioned Roles share similarities. Both are essentially a collection of rights, but the intended use is very different. Basically, Rights Bundles should be used when you want to limit specific rights to one or more tenants. Roles should be used to limit specific rights to one or more users.

The main differences are:

	Rights Bundles	Roles
Usage	Limits rights to Org	Limits rights to Users
Assignment	Organizations	Users
Defined at level	Global	Global / Org
Defined by	Sys Admin	Global: Sys Admin Org: Org Admin

The flowchart below summarizes it very well.

Advised Usage for Rights Bundles

Limit usage of specific features by the Service Provider to one or more tenants.

• Limit the usage of specific features to tenants. For example, to limit the usage of OSPF for all or specific Tenants. A use case could be to prevent the usage of the feature, since is not available in NSX-T and the Service Provider plans for an upcoming migration from V to T.

Federation

The Org federation option is available per tenant and brings a ton of additional features to the vCD product by setting up a one way trust relationship. Only a single IdP can be federated. The federation option can be configured by the Service Provider or by the Org Admin itself to point to their own Identity Provider (IdP). If needed, Service Providers can help a tenant setting up the federation.

Use cases for federation are:

• Tenants want to us their own corporate accounts to logon to vCD
• Password policies with additional complexity
• Multi-factor (MFA) / 2 factor (2FA) authentication

vCD supports only SAML v2 for federation. When the IdP of choice supports SAML v2 (most do) it can probably be used. Tomas Fojta wrote on his blog posts about configuring vCD with some common used IdP solutions.

Some common used IdP’s are:

• Azure AD
• Keycloak
• Microsoft AD FS
• VMware Identity Manager (vIDM)

After federation is configured, users and groups that exist in the IdP solution can be used in vCD. This way, centrally configured account and groups of the tenant can be assigned vCD roles.

In the example above, all default available Global Roles are configured as groups in the IdP solution using a Keycloak based IdP solution. This way the IdP is the source of truth for user and group management. Users can then login with their own (corporate) credentials and password to perform the tasks needed in the vCD.

The basic login workflow when federation is configured is:

1. User accesses the vCD portal
2. User is re-directed to tenant IdP solution
3. User logs in
4. IdP checks login with vCD
5. Access to vCD granted

When vCD is federated with a multi-factor authentication (MFA) capable IdP solution, it can be used to protect the vCD tenant portal. MFA configuration is typically done from within the IdP or MFA solution, not within vCD.

The common used IdP solutions mentioned above can be use together with many of the MFA solutions available.

Some examples of MFA solutions are:

• Azure MFA
• DUO MFA
• Google Authenticator
• Ping MFA
• RSA

Besides SAML, vCD also supports the use of (S)LDAP as an identity source for tenants. My personal opinion is to avoid the use of LDAP for tenants because vCD cell servers needs to be able to access a tenants LDAP system.

LDAP systems are normally not connected over the Internet and most Service Providers don’t like the idea that their vCD cell servers need to communicate over some special network path to their tenants LDAP systems.

Other possible issues to expect with LDAP systems are password expiration and complexity issues. Also MFA solutions cannot be used together with LDAP based identity sources.

To summarize the federation section, a tenant that has configured vCD to federate with a common IdP, can also implement MFA solutions. The IdP and MFA solution together can implement all the necessary level of account and password protections needed for a tenant.

vApps

vApps are the main construct for grouping VM’s in vCD. The vApp Owner and Org Admin both have the ability to implement the proper permissions. This section describes the options for securing vApp access.

Members of the Org Admin role have full access to all vApps and VM’s within the whole vCD Organization and are able to change vApp ownerships. Org Admins also see all the vApps in the Organization.

All other Users and Groups only see the vApps they own or vApp that have been shared to them.

vApp Owner

Every vApp can only have a single Owner. The user that creates the vApp is the initial Owner. The Owner has full access to the vApp and all of the VM’s in it, but cannot assign a different Owner.

vApp Access

To control vApp access and visibility make use of the three Global Roles are available by default. The table below sums this up.

	Org Admin	Catalog Author	vApp Author	vApp User	Console Only
Change Owner	Y	N	N	N	N
Create vApps	Y	Y	Y	N	N
Delete vApps	Y	Y	Y	Y	N
Share vApp	Y	Y	Y	Y	N

vApp Sharing

Most of the default Roles have the right to delegate (Share) access to specific Users and Groups or the whole Organization by using the vApp Sharing option as can be seen in the table above. The two possible Sharing permissions are “Read-Only” and “Full Control”.

The “Full Control” permissions give Users or Groups the rights to: Open, start, save a vApp as a vApp template, add the template to a catalog, copy to a catalog and modify properties.

The second part can be found using the link below:

vCloud Director Identity and Access Management – Part 2

Useful links

This section contains the link that are relevant to this part of the series.

Tomas Fojta’s blog

Wikipedia article explaining IAM

vCD Tenant Admin product documentation

vCD documentation describing the predefined roles and their rights

vCD documentation describing the management of rights bundles

VMware Cloud Provider Blog – Simple Rights Management with Bundles