Identity Provider Federation for vCenter Server

Starting with vSphere 7.0, you can replace through federation your built-in vCenter Server identity source with an external identity source. Depending on your vCenter Server version, you can use external identity providers such as AD FS, Azure AD, or Okta.

With identity federation, you can use the same corporate identity source for your vCenter Server that you use for your other federated desktop and cloud applications.

vCenter Server Identity Provider Federation Basics

In vSphere 7.0 and later, vCenter Server supports federated authentication. In this scenario, when a user logs in to vCenter Server, vCenter Server redirects the user login to the external identity provider. The user credentials are no longer provided to vCenter Server directly. Instead, the user provides credentials to the external identity provider. vCenter Server trusts the external identity provider to perform the authentication. In the federation model, users never provide credentials directly to any service or application but only to the identity provider. As a result, you "federate" your applications and services, such as vCenter Server, with your identity provider.

Why Is Identity Provider Federation Useful

Federating vCenter Server to an enterprise identity provider alleviates the burden of identity management and provides flexible options such as multifactor authentication (MFA), automatic registration and termination of users across services, and many more. Identity provider federation uses token-based authentication and minimizes the risk of bad actors acquiring protected credentials such as user names and passwords. Identity provider federation also helps your organization with compliance as various international standards require MFA to guarantee data security. In addition, with identity provider federation, you can automate vCenter Server user management because you utilize the users and groups from your enterprise identity source.

vCenter Server External Identity Provider Support

vCenter Server supports the following external identity providers:

AD FS (vSphere 7.0 and later)
Okta (vSphere 8.0 Update 1 and later)
Microsoft Entra ID, formerly called Azure AD (vSphere 8.0 Update 2 and later)
PingFederate (starting in vSphere 8.0 Update 3)

Federation to Microsoft Active Directory Federation Services (AD FS)

In vSphere 7.0 and later, you can activate identity federation to Microsoft Active Directory Federation Services (AD FS). In this scenario, vCenter Server federates directly to the enterprise identity provider, AD FS, without the use of an authentication intermediary service.

You can configure federation to AD FS with the help of the vSphere Automation API. For more information, see Federate vCenter Server to Microsoft Active Directory Federation Services (AD FS).

Federation to Okta and Azure AD Through VMware Identity Broker - vCenter Server

Starting from vSphere 8.0 Update 1, you can activate federation to Okta as the identity provider. Starting from vSphere 8.0 Update 2, you can activate federation to Azure AD as the identity provider. Both configurations use VMware Identity Broker - vCenter Server, an authentication intermediary that functions as a built-in container within vCenter Server. With VMware Identity Broker - vCenter Server, you can configure principals to authenticate to vCenter Server by using an external identity provider.

vCenter Server can support the default vsphere.local identity source and only one configured external identity provider. You cannot use multiple external identity providers.

Once you set up your federated authentication, you can use OAuth for login to vCenter Server.

Note:

You can federate vCenter Server to Okta or Azure AD by using the vSphere Client. For more information, see Configure vCenter Server Identity Provider Federation for Okta and Configure vCenter Server Identity Provider Federation for Azure AD in the vSphere Authentication Guide.

Authentication to a Federated vCenter Server

Once you have configured vCenter Server to point to AD FS, Okta, or Azure AD, you can use the vSphere Automation and the VMware Identity Broker - vCenter Server APIs to authenticate principals to your vCenter Server. Depending on the type of user or application you want to authenticate, you can choose among different token-based authentication options. vSphere supports the various OAuth 2.0 grant types.

What is OAuth 2.0

OAuth 2.0 is an open authorization framework that allows information exchanges among web services without exposing sensitive data such as user names and passwords. OAuth 2.0 boosts security and prevents malicious actors from stealing users' credentials over the Internet. OAuth 2.0 is an open framework and can be customized according to the organizational requirements.

You can use different OAuth 2.0 grant types to authenticate your applications to vCenter Server. The OAuth grant types represent different methods by which a principal can obtain an access token from an authorization server. In the vSphere implementation, the access token is used to obtain a SAML token and authenticate principals to vCenter Server.

OAuth 2.0 Grant Types

Password: In the Password grant type, the client application exchanges the user's credentials, user name and password, for an access token, and optionally an ID token (JWT tokens), from the authorization server. OAuth 2.0 has been designed to prevent the exchange of user credentials, so the Password grant type must be avoided whenever possible, especially for third-party application authentication. The latest OAuth 2.0 Security Best Current Practice recommends avoiding the Password grant type altogether. As a single-factor method, the Password grant type is incompatible with the requirements of multifactor authentication (MFA). For more information, see Authenticate to an AD FS-Federated vCenter Server by Using the Password Grant Type.

Important: The Password grant type is disallowed by the latest OAuth 2.0 Security Best Current Practice. The Password grant is excluded entirely from OAuth 2.1.
Authorization Code: In the Authorization Code grant type, the client application uses an authorization code to obtain JWT tokens from the authorization server. This grant type requires a user to verify an authentication request through a web browser. The Authorization Code grant type is compatible with multi-factor authentication and guarantees a substantial degree of security. This grant type is appropriate for regular web applications running on a server. For more information, see Authenticate to an AD FS - Federated vCenter Server by Using the Authorization Code Grant Type.
Client Credentials: The Client Credentials grant type permits web services to authenticate to other web services without the involvement of a user. This grant type is useful for applications that are resource owners and can take advantage of headless, or backend automation, when a physical user is not present. For example, a client application might use this grant type to authenticate and fetch details about a virtual environment.
Refresh Token: The Refresh Token grant type is used by clients to exchange an expiring access token for a refresh token that can be used to receive a new access token. With this grant type, a client application can fetch a valid access token without asking the user to log in again. It allows client applications to provide a seamless user experience without further interaction with the user after timeouts.

What Is OpenID Connect (OIDC)

The vSphere implementation of OAuth 2.0 uses the OpenID Connect (OIDC) authentication protocol. With OIDC, the authorization server returns an ID token containing data about who the users are and what permissions they have on the resource server. As a result, vCenter Server can identify users and grant them the respective permissions that are defined on the authorization server.