vCenter Single Sign-On allows vSphere components to communicate with each other through a secure token mechanism.

vCenter Single Sign-On uses the following services.
  • Authentication of users through either external identity provider federation or the vCenter Server built-in identity provider. The built-in identity provider supports local accounts, Active Directory or OpenLDAP, Integrated Windows Authentication (IWA), and miscellaneous authentication mechanisms (smart card, RSA SecurID, and Windows Session Authentication).
  • Authentication of solution users through certificates.
  • Security Token Service (STS).
  • SSL for secure traffic.

Identity Provider Overview

Before vSphere 7.0, vCenter Server includes a built-in identity provider. By default, vCenter Server uses the vsphere.local domain as the identity source (but you can change it during installation). You can configure the vCenter Server built-in identity provider to use Active Directory (AD) as its identity source using LDAP/S, OpenLDAP/S, and Integrated Windows Authentication (IWA). Such configurations allow customers to log in to vCenter Server using their AD accounts.

Starting with vSphere 7.0, you can configure vCenter Server for an external identity provider using federated authentication. In such a configuration, you replace vCenter Server as the identity provider. Currently, vSphere supports Active Directory Federation Services (AD FS) as the external identity provider. In this configuration, AD FS interacts with the identity sources on behalf of vCenter Server.

User Login with vCenter Server Identity Provider Federated Authentication

The following figure shows the user login flow for vCenter Server Identity Provider Federation.

Figure 1. vCenter Server Identity Provider Federation User Login

This figure shows the process flow of a user logging in to vCenter Server with Identity Provider Federation.

vCenter Server, AD FS, and Active Directory interact as follows:

  1. The user starts on the vCenter Server landing page by entering a user name.
  2. If the user name is for a federated domain, vCenter Server redirects the authentication request to AD FS.
  3. If needed, AD FS prompts the user to log in with Active Directory credentials.
  4. AD FS authenticates the user with Active Directory.
  5. AD FS issues a security token with group information from Active Directory.
  6. vCenter Server uses the token to log in the user.
The user is now authenticated, and can view and modify any objects that the user's role has privileges for.
Note: Initially, each user is assigned the No Access role. A vCenter Server administrator must assign the user at least to the Read Only role before the user can log in. See the vSphere Security documentation.

In case the external identity provider is unreachable, the login process falls back to the vCenter Server landing page, showing an appropriate information message. Users can still log in using their local accounts in the vsphere.local identity source.

User Login with the vCenter Server Built-In Identity Provider

The following figure shows the user login flow when vCenter Server acts as the identity provider.

Figure 2. User Login with the vCenter Server Built-In Identity Provider
When the user logs in to the vSphere Client, the Single Sign-On server establishes the authentication handshake.
  1. A user logs in to the vSphere Client with a user name and password to access the vCenter Server system or another vCenter service.

    When Integrated Windows Authentication (IWA) has been configured, users can also log in without having to reenter their Windows password by checking the Use Windows session authentication check box.

  2. The vSphere Client passes the login information to the vCenter Single Sign-On service, which checks the SAML token of the vSphere Client. If the vSphere Client has a valid token, vCenter Single Sign-On then checks whether the user is in the configured identity source (for example Active Directory).
    • If only the user name is used, vCenter Single Sign-On checks in the default domain.
    • If a domain name is included with the user name (DOMAIN\user1 or user1@DOMAIN), vCenter Single Sign-On checks that domain.
  3. If the user can authenticate to the identity source, vCenter Single Sign-On returns a token that represents the user to the vSphere Client.
  4. The vSphere Client passes the token to the vCenter Server system.
  5. vCenter Server checks with the vCenter Single Sign-On server that the token is valid and not expired.
  6. The vCenter Single Sign-On server returns the token to the vCenter Server system, using the vCenter Server Authorization Framework to allow user access.
The user is now authenticated, and can view and modify any objects that the user's role has privileges for.
Note: Initially, each user is assigned the No Access role. A vCenter Server administrator must assign the user at least to the Read Only role before the user can log in. See the vSphere Security documentation.

Login for Solution Users

Solution users are sets of services that are used in the vCenter Server infrastructure, for example, vCenter Server extensions. VMware extensions and potentially third-party extensions might also authenticate to vCenter Single Sign-On.

Note: vCenter Server uses solution user certificates for internal communication only. Solution user certificates are not used for external communication.

The following figure shows the login flow for solution users.

Figure 3. Login for Solution Users
The handshake between a solution user, vCenter Single Sign-On, and other vCenter components follows the steps in the following text.
  1. The solution user attempts to connect to a vCenter Server service.
  2. The solution user is redirected to vCenter Single Sign-On. If the solution user is new to vCenter Single Sign-On, it has to present a valid certificate.
  3. If the certificate is valid, vCenter Single Sign-On assigns a SAML token (bearer token) to the solution user. The token is signed by vCenter Single Sign-On.
  4. The solution user is then redirected to vCenter Single Sign-On and can perform tasks based on its permissions.

    The next time the solution user has to authenticate, it can use the SAML token to log in to vCenter Server.

By default, this handshake is automatic because VMCA provisions solution users with certificates during startup. If your company policy requires third-party CA-signed certificates, you can replace the solution user certificates with third-party CA-signed certificates. If those certificates are valid, vCenter Single Sign-On assigns a SAML token to the solution user. See Use Custom Certificates with vSphere.

Supported Encryption

AES encryption, which is the highest level of encryption, is supported. The supported encryption affects security when vCenter Single Sign-On uses Active Directory as an identity source.

It also affects security anytime an ESXi host or vCenter Server is joined to Active Directory.