To obtain a security token from a vCenter Single Sign On Server, the vCenter Single Sign On client calls the Issue method, which sends a SOAP message that contains a token request and authentication data. This section describes a token request that uses a certificate to obtain a holder-of-key token. When the client creates the token request, it also inserts timestamp, signature, and certificate data into the SOAP security header. The vCenter Single Sign On SDK provides Java packages that support SOAP header manipulation.
The following figure represents the content of an Issue request and the response containing a SAML token.
When the vCenter Single Sign On Server receives the issue request, it performs the following operations to generate a token:
|
■
|
Uses the certificate subject to authenticate the request. Authentication is obtained from the identity store that is registered with the vCenter Single Sign On Server.
|
|
■
|
Generates a token that specifies the principal – the vCenter Single Sign On client – as the token subject.
|
Web service security policies define the requirements for secure communication between a Web service and a client. vCenter Single Sign On security policies are based on the WS-Policy framework and WS-SecurityPolicy specifications. A policy identifies specific elements for token requests. Based on the policy requirements, a vCenter Single Sign On client will insert data into the SOAP security header for the token request.
vCenter Single Sign On defines security policies for end user access, solution access, and for token exchange. The policies stipulate the following elements:
vCenter Single Sign On security policies specify that the body of the SOAP message for a holder-of-key token must be signed. Bearer tokens require only the username and timestamp tokens.
|
Note The vCenter Single Sign On Server issues SAML tokens to represent client authentication. The standards documentation also uses the term “token” to refer to claims and certificate data that is inserted into SOAP security headers.
|
The following table shows the vCenter Single Sign On policies and identifies the requirements for each policy. The vCenter Single Sign On WSDL defines these policies for use with the vCenter Single Sign On methods.
|
Defines the transport policy and algorithm suite for all communication with the vCenter Single Sign On Server:
|
|||||
|
Defines the security policy for Issue token requests. IssueRequestPolicy specifies either username token (signed), username token (plaintext password), X509 certificate, or holder-of-key token authentication. You specify username/password or X509 certificate credentials to obtain a vCenter Single Sign On token. If you obtain a holder-of-key token, you can use that token for subsequent Issue requests.
|
|||||
|
Defines the security policy for Renew token requests. The request must contain one of the following endorsing supporting tokens. The SOAP message body must be included in the signature generated with the token.
|
The vCenter Single Sign On SDK provides Java utilities that support the vCenter Single Sign On security policies. Your vCenter Single Sign On client can use these utilities to create digital signatures and supporting tokens, and insert them into SOAP headers as required by the policies. The SOAP header utilities are defined in files that are located in the samples directory:
When a vCenter Single Sign On client connects to a vCenter Single Sign On server, it must specify the server URL as the endpoint for the token request message. The endpoint specification uses the following format:
The port number and path suffix (7444/ims/STSService) is required. 7444 is the default port number. See Sending a Request for a Security Token for an example of setting the endpoint for a token request. You can change the port number during vCenter Single Sign On Server installation.
Holder-of-key tokens can be delegated to services in the vSphere environment. A service that uses a delegated token performs the service on behalf of the principle that provided the token. A token request specifies a DelegateTo identity. The DelegateTo value can either be a solution token or a reference to a solution token.
Components in the vSphere environment can use delegated tokens. vSphere clients that use the LoginByToken method to connect to a vCenter Server do not use delegated tokens. The vCenter Server will use a vSphere client’s token to obtain a delegated token. The vCenter Server will use the delegated token to perform operations on behalf of the user after the user’s vCenter session has ended. For example, a user may schedule operations to occur over an extended period of time. The vCenter Server will use a delegated token to support these operations.
A SAML token contains information about the lifetime of a token. A SAML token uses the NotBefore and NotOnOrAfter attributes of the SAML Conditions element to define the token lifetime.
During a token’s lifetime, the vCenter Single Sign On server considers any request containing that token to be valid and the server will perform renewal and validation operations on the token. The lifetime of a token is affected by a clock tolerance value that the vCenter Single Sign On server applies to token requests. The clock tolerance value accounts for differences between time values generated by different systems in the vSphere environment. The clock tolerance is 10 minutes.
The vCenter Single Sign On Server supports the use of SSPI (Security Support Provider Interface) for client authentication. SSPI authentication requires that both the client and server use security providers to perform authentication. At the beginning of a vCenter Single Sign On Server session, the vCenter Single Sign On client and vCenter Single Sign On Server exchange data. Each participant will use its security provider to authenticate the data it receives. The authentication exchange continues until both security providers authenticate the data.
The vCenter Single Sign On client API provides a challenge request for client participation in SSPI authentication. The following sequence describes the challenge protocol.
|
■
|
vCenter Single Sign On client sends an issue request to the vCenter Single Sign On Server. The request contains the client credentials.
|
|
■
|
vCenter Single Sign On Server uses its security provider to authenticate the client. The Server returns a RequestSecurityTokenResponseType object in response to the issue request. The response contains a challenge.
|
|
■
|
vCenter Single Sign On client uses its security provider to authenticate the vCenter Single Sign On Server response. To continue the authentication exchange, the client sends a challenge request to the vCenter Single Sign On Server. The request contains the resolution to the Server’s challenge and it can also contain a challenge from the vCenter Single Sign On client.
|
|
■
|
vCenter Single Sign On Server uses its security provider to authenticate the client’s response. If there are still problems, the Server can continue the authentication exchange by returning a response with an embedded challenge. If authentication is successful, the vCenter Single Sign On Server returns a SAML token to complete the original issue request.
|
To exchange challenge data, the vCenter Single Sign On client and vCenter Single Sign On Server use the following elements defined for both RequestSecurityTokenType and RequestSecurityTokenResponseType objects.