vCenter Single Sign-On allows vSphere components to communicate with each other through a secure token mechanism instead of requiring users to authenticate separately with each component.

vCenter Single Sign-On uses a combination of STS (Security Token Service), SSL for secure traffic, and authentication of human users through Active Directory or OpenLDAP and of solution users through certificates.

vCenter Single Sign-On Handshake for Human Users

The following illustration shows the handshake for human users.

Figure 1. vCenter Single Sign-On Handshake for Human Users
When the user logs in to the vSphere Web Client, the Single Sign-On server establishes the authentication handshake.
  1. A user logs in to the vSphere Web Client with a user name and password to access the vCenter Server system or another vCenter service.

    The user can also log in without a password and check the Use Windows session authentication checkbox.

  2. The vSphere Web Client passes the login information to the vCenter Single Sign-On service, which checks the SAML token of the vSphere Web Client. If the vSphere Web 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 Web Client.

  4. The vSphere Web 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. ThevCenter Single Sign-On server returns the token to the vCenter Server system, leveraging thevCenter Server Authorization Framework to allow user access.

The user can now authenticate, 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 Add a Permission to an Inventory Object.

vCenter Single Sign-On Handshake for Solution Users

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

Figure 2. vCenter Single Sign-On Handshake for Solution Users
The handshake between a solution user, vCenter Single Sign-On, and other vCenter components follows the steps in the text below.

For solution users, the interaction proceeds as follows:

  1. The solution user attempts to connect to a vCenter 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.

  5. 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 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 Third-Party Certificates With vSphere.