vCenter Single Sign-On allows vSphere components to communicate with each other through a secure token mechanism.
- 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.
vCenter Server, AD FS, and Active Directory interact as follows:
- The user starts on the vCenter Server landing page by entering a user name.
- If the user name is for a federated domain, vCenter Server redirects the authentication request to AD FS.
- If needed, AD FS prompts the user to log in with Active Directory credentials.
- AD FS authenticates the user with Active Directory.
- AD FS issues a security token with group information from Active Directory.
- vCenter Server uses the token to log in the user.
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.
- 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.
- 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.
- If the user can authenticate to the identity source, vCenter Single Sign-On returns a token that represents the user to the vSphere Client.
- The vSphere Client passes the token to the vCenter Server system.
- vCenter Server checks with the vCenter Single Sign-On server that the token is valid and not expired.
- The vCenter Single Sign-On server returns the token to the vCenter Server system, using the vCenter Server Authorization Framework to allow user access.
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.
The following figure shows the login flow for solution users.
- The solution user attempts to connect to a vCenter Server service.
- 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.
- 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.
- 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.
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.