VMware Cloud Director

Remap VMware Cloud Director™️ users to new Identity Providers – Part 1: Provider users

VMware Cloud Director has a new feature added in 10.4.1 release which provides flexibility to change Identity Providers as per your choice and convenience, without losing the resources assigned to the users. VMware Cloud Director supports Lightweight Directory Access Protocol (LDAP), Security Assertion Markup Language (SAML) and OpenId Connect (OIDC) protocols for authentication. You can switch between these protocols or migrate to a different identity provider with ease by remapping existing users to their identity in another Identity Provider. This blog demonstrates how to use the user management API to accomplish this.

Additionally, VMware Cloud Director has announced the deprecation of support for local users starting with 10.4.1 release (release notes). VMware Cloud Director’s industry-compliant integrations with external Identity Providers supplies benefits of most modern and secure authentication schemes to its customers. Customers can avail all the features such as Two Factor Authentication/Multi Factor Authentication, biometric integrations, smart card integrations, etc. with VMware Cloud Director. It also aids customers staying up to date with all future advancements in authentication technologies.

Following is an example to remap provider (local) user to a SAML identity provider federation. As of VMware Cloud Director 10.4.1, remapping a user is available only as an API feature. Thus, for all subsequent steps use an API client of your choice. In my examples below, I am using Postman to perform remapping.

Pre-requisite: Make sure the Identity Provider federation to which you want to remap user to is accurately configured.

  1. Login to VMware Cloud Director as an administrator (tenant or system administrator) and identify the user you want to remap. Here, the user I am remapping is ‘demouser’. This user is a local user.
  1. Login using the API as the administrator; either using their credentials (local or LDAP), IDP issued tokens (SAML or OAuth) or VMware Cloud Director’s API Token.
    API: POST “https”//{api_host}/cloudapi/1.0.0/sessions” TextDescription automatically generated
  1. Retrieve the urn id of ‘demouser’ from query users API.
    API: GET “https://{api_host}/cloudapi/1.0.0/users” TextDescription automatically generated
    Now, using this urn id, fetch complete information of the user. Refer to Get User for more insight on this API.
    API: GET “https://{api_host}/cloudapi/1.0.0/users/urn:vcloud:user:bafe9a31-1810-4108-8754-3ece52a4e963”
  1. Copy complete information of the user from previous step and edit following properties for use as body of the subsequent PUT request.
    • Update the ‘username’ to reflect the user’s username in the new Identity Provider. While this example shows a distinct username being used, it is possible to have simpler updates like switching from username to email address, etc.
    • Update the ‘providerType’ based on the type of new Identity Provider. New values of ‘providerType’ could be OIDC, SAML, LOCAL, LDAP.

    Send PUT request for the user to be remapped. Refer to update user for more insight on this API.
    API: PUT “https://{api_host}/cloudapi/1.0.0/users/urn:vcloud:user:bafe9a31-1810-4108-8754-3ece52a4e963”

The user ‘demouser’ has now been remapped to the tenant’s SAML identity provider and their username has been remapped to ‘[email protected]’.

Users can be remapped from one IDP federation to another using the same process. If you are remapping a user to ‘LOCAL’ provider type, in addition to updating the provider type update password in the body of PUT request.

In next part of this blog series, we will remap a tenant user.

Check out all of the latest improvements in VMware Cloud Director 10.4.