VMware vSphere SDKs and Tools 8.0

8.0 7.0 6.7 6.5

Identity Provider Federation for
vCenter Server
Last Updated December 16, 2024

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
.
You can federate
vCenter Server
 to Okta or Azure AD by using the
vSphere Client
. For more information, see and in the
vSphere Authentication Guide
.
Once you have configured
vCenter Server
 to point to AD FS, you can use the
vSphere Automation
 API 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.
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.

Content feedback and comments