How vCenter Single Sign-On Protects Your Environment

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 the following services.

• STS (Security Token Service).
• SSL for secure traffic.
• Authentication of human users through Active Directory or OpenLDAP.
• Authentication 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

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 check box.

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. 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 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 the vSphere Security documentation.

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

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 Custom Certificates With vSphere.

Supported Encryption

AES encryption, which is the highest level of encryption, is supported.

The supported encryption affects security any time an ESXi host or vCenter Server is joined to Active Directory. It also affects security when vCenter Single Sign-On uses Active Directory as an identity source.