vCenter Single Sign-On Overview

To support the requirements for secure software environments, software components require authorization to perform operations on behalf of a user. In a single sign-on environment, a user provides credentials once, and components in the environment perform operations based on the original authentication. vCenter Single Sign-On authentication can use the following identity store technologies:

■	Windows Active Directory

■	OpenLDAP (Lightweight Directory Access Protocol)

■	Local user accounts (vCenter Single Sign-On server resident on the vCenter server machine)

■	vCenter Single Sign-On user accounts

For information about configuring identity store support, see vSphere Installation and Setup and vSphere Security in the VMware Documentation Center.

In the context of single sign-on, the vSphere environment is a collection of services and solutions, each of which potentially requires authentication of clients that use the service or solution. Examples of solutions that might support single sign-on include vShield, SRM (Site Recovery Manager), and vCO (vCenter Orchestrator). Because a service can use another service, single sign-on provides a convenient mechanism to broker authentication during a sequence of vSphere operations.

A vCenter Single Sign-On client connects to the vCenter Single Sign-On server to obtain a token that represents the client. The vCenter Single Sign-On server provides a Security Token Service (STS). A token uses the Security Assertion Markup Language (SAML), which is an XML encoding of authentication data. It contains a collection of statements or claims that support client authentication. Examples of token claims include name, key, and group.

 

 

There are two types of vCenter Single Sign-On tokens.

■

Holder-of-key tokens provide authentication based on security artifacts embedded in the token. Holder-of-key tokens can be used for delegation. A client can obtain a holder-of-key token and delegate that token for use by another entity. The token contains the claims to identify the originator and the delegate. In the vSphere environment, a vCenter server obtains delegated tokens on a user’s behalf and uses those tokens to perform operations.

■

Bearer tokens provide authentication based only on possession of the token. Bearer tokens are intended for short-term, single-operation use. A bearer token does not verify the identity of the user (or entity) sending the request. It is possible to use bearer tokens in the vSphere environment, however there are potential limitations:

■	The vCenter Single Sign-On server may impose limitations on the token lifetime, which would require you to acquire new tokens frequently.

■	Future versions of vSphere might require the use of holder-of-key tokens.

Single Sign-On in the vSphere Environment – vCenter Server LoginByToken shows a vCenter client that uses a SAML token to establish a session with a vCenter server.

Single Sign-On in the vSphere Environment – vCenter Server LoginByToken

The vCenter client also operates as a vCenter Single Sign-On client. The vCenter Single Sign-On client component handles communication with the vCenter Single Sign-On server.

1

The vCenter Single Sign-On client sends a token request to the vCenter Single Sign-On server. The request contains information that identifies the principal. The principal has an identity in the identity store. The principal may be a user or it may be a software component. In this scenario, the principal is the user that controls the vCenter client.

2	The vCenter Single Sign-On server uses the identity store to authenticate the principal.

3	The vCenter Single Sign-On server sends a response to the token request. If authentication is successful, the response includes a SAML token.

4	The vCenter client connects to the vCenter server and calls the SessionManager.LoginByToken method. The login request contains the SAML token.

Single Sign-On in the vSphere Environment – vCenter Server LoginByToken shows the vCenter server, vCenter Single Sign-On server, and identity store as components running on separate machines. You can use different vCenter Single Sign-On configurations.

■	A vCenter Single Sign-On server can operate as an independent component running on its own machine. The vCenter Single Sign-On server can use a remote identity store or it can manage user accounts in its own internal identity store.

■	A vCenter Single Sign-On server can operate as an embedded component running on the vCenter server machine. In this configuration, the vCenter Single Sign-On server can use a remote identity store, its own internal identity store, or it can access user accounts on the vCenter server machine.

For information about installing and configuring the vCenter Single Sign-On server, see vSphere Installation and Setup and vSphere Security in the VMware Documentation Center.