7. vCloud Security Examples : 7.2 Single Sign-On (SSO) – Consumer : 7.2.2 Use Case
7.2.2 Use Case
The Web single sign-on (SSO) feature and configuration are exposed through vCloud Director and can be used in both service provider and consumer architecture. The following are several use cases that can be used:
*Between a single client and multiple back end servers.
*Solution-to-solution authentication.
*Delegation and renew.
These use cases are further explored in the following sections. Between a Single Client and Multiple Back End Servers
The classic single sign-on (SSO) use case is the single sign-on between a single client and multiple back end services. A user accesses multiple back end 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 other back end servers. The following figure illustrates this use case.
Figure 32. Single Sign-On (SSO) Between a Client and Multiple Back End Services Solution-to-Solution Authentication
With solution-to-solution authentication, the goal is to assign an SSO user to each of the solutions. In this use case two solutions communicate with each other. Before they start to communicate they must prove each other's identity. The solution that initiates communication requests from the SSO server issues a SAML token which 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 must be registered with its public key in the SSO server. The following figure illustrates this use case.
Figure 33. SSO Solution-to-Solution Authentication Delegation
Executing tasks on behalf of a user is referred to as delegation. In this example use case, some workflows, which an end user initiates, might require multiple solutions to communicate with each other. This use case shows the SSO support for such work flows. Before the user can initiate the workflow through a given UI, the user must provide credentials. The UI then validates those credentials against the SSO server, which issues a SAML token. Then the user decides to initiate 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 so-called “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. The following figure illustrates this use case.
Figure 34. Task Execution on Behalf of a User Delegation and Renew
Delegation and renew defines scheduling a long-lived task. Some long running operations in the infrastructure require long running tasks to be executed in the absence of the end user who has initiated them. The SSO server supports such tasks using 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 passes that token to the solution, which performs that long running task. The solution persists the token in a non-secured way, as the token is self-secured. Each time the task gets activated, the solution reads the token from the disk and goes to the SSO server to renew it. By going to the SSO server for the renewal, the solution has the guarantee that the user has not previously deleted it from the system. This use case is illustrated in the following figure.
Figure 35. Single Sign-On for Long-Lived Tasks