The Web Single Sign-On (SSO) feature and configuration are exposed through VMware vCloud Director 5.1 and can be used in both service provider and consumer architecture. There following are several example use cases.

This use case is the Single sign-on (SSO) between a single client and multiple backend services. This is the classical single sign-on SSO use case. In this case, a user accesses multiple backend servers through a single UI client. The user provides credentials to the UI client only once, which validates them against the SSO server. If the validation is successful the SSO server issues a SAML token, which then can be used by the UI client to access the different backend servers. The following diagram shows this use case.

This use case is the solution-to-solution authentication. The goal of this use case is to assign an SSO user to each of the solutions. In this use case we have two solutions that need to communicate with each other. Before they start to communicate they need to prove each other's identity. To do so, the solution, initiates the communication requests from the SSO server to issue a SAML token that asserts its identity. As part of this request the solution proves its identity using its own private key. After the SSO server has issued a token the solution can use that token to access any other solution as if it is a normal user. For this use case to work each solution needs to be registered with its public key in the SSO server.

This use case executes tasks on behalf of a user, which is referred to as delegation. In this use case, some workflows that an end user initiates might require multiple solutions to communicate with each other. This use case shows the SSO support for such workflows. Before the user can initiate the workflow through a given UI the user needs to provide credentials. The UI then validates those credentials against the SSO server, which issues a SAML token. Then, the user initiates a workflow, which requires Solution-1 to access Solution-2 and Solution-3 on behalf of the end user. As part of this process the UI requests from the SSO server a delegated token for Solution-1 by providing the SAML token of the end user. The delegated token asserts that the user has granted Solution-1 the privileges to execute tasks on the user' s behalf. After the UI has the delegated token it gives it to Solution-1, which then can use it to log in to Solution-2 and Solution-3.

This use case defines the scheduling of long-lived tasks, and is referred to as delegation and renew. Some long running operations in the infrastructure require long running tasks to be executed in the absence of the end user who initiated them. The SSO server supports such tasks by the means of delegated and renewable tokens. After a long running task has been identified the UI obtains from the SSO server a delegated and renewable token. It then passes that token to the solution, which performs the long running task. The solution persists the token in a non-secured way, as the token is self-secured. Every time the task gets activated the solution reads the token from the disk and goes to the SSO server to renew it. Going to the SSO server for the renewal the solution prevents the user from being deleted from the system in the meantime.