3.1 Single Sign-on Using a Security Token Service and WS-Federation

Use case diagram for single sign-on with WS-Federation

Figure 3: Use case diagram for single sign-on with WS-Federation

Goal

To obtain a security token for use when signing on to web resources without requiring user intervention.

Context of Use

A user wishes to use a number of resources that are accessible through the Internet, but does not wish to log on to each resource separately. Alternatively, the user wishes to use one resource multiple times, but does not wish to log on to the resource each time it is used. See [WSFederation], [WSFederation1.2], and, more specifically, the Microsoft Web Browser Federated Sign-On Protocol [MS-MWBF] for reference.

Actors

  • User: The person who wishes to use a web resource, which is controlled by the relying party (defined following).

  • Client: The network entity that the user uses to request the web resource. In the case of WS-Federation, specifically [MS-MWBF], this is a web browser.

  • Relying Party: The relying party (RP) is the network entity that controls access to the web resource, and is typically some type of resource server. It relies on AD FS for security tokens that it can use to make security decisions about the user or client.

  • STS: For the purpose of this use case, the security token service (STS) handles authentication for the RP.

  • AD FS Server: The AD FS server authenticates the user and provides security tokens to the RP (possibly through the STS that authenticates for the RP) so that the RP can make security decisions about the user or client.

    Note The AD FS server is itself an STS, and in some cases, the AD FS server provides authentication for the RP and also authenticates the user.

  • Active Directory: Active Directory is the identity store that the AD FS server contacts for authentication information about the user.

Preconditions

A web resource exists that is needed by a user. The resource is protected by an entity, the RP that relies on AD FS (directly or indirectly) for authentication of the user.

Main success scenario

  1. Trigger: The user interacts with the client (that is, a web browser) to connect with a web resource.

  2. The client sends a request for the web resource to the appropriate address.

  3. The RP redirects the client to the STS that it uses for authentication.

    Note In this scenario, the user and the RP are in different security realms. The STSs in the security realms have established a federation partnership.

  4. The STS that authenticates for the RP redirects the client to the STS that authenticates the user, that is, the AD FS server.

  5. The AD FS server authenticates the user, either for the first time by querying the user, or for subsequent times by using information that is stored on the client and at the AD FS server. Active Directory supports the AD FS server for this task as needed.

  6. The AD FS server creates the security information needed by the STS that authenticates for the RP and sends the information to the client.

  7. The client sends the security information on to the STS that authenticates for the RP.

  8. The STS that authenticates for the RP creates the security information needed by the RP, for example, the security token, and sends the information to the client.

  9. The client reconnects with the web resource, and includes the security information that was created by the STS that authenticates for the RP.

Post condition

The user has obtained appropriate access to the web resource.

Variation: Single security realm

In this variation, the user and RP are in the same security realm.

1-3. Same as the main success scenario except that the user and RP are in the same security realm; the STS that authenticates for the RP is also the AD FS server.

4. The AD FS server authenticates the user, either for the first time by querying the user, or for subsequent times by using information that is stored on the client and at the AD FS server. Active Directory supports the AD FS server for this task as needed.

5. The AD FS server creates the security information needed by the RP, for example, the security token, and sends the information to the client.

6. The client reconnects with the web resource, and includes the security information that was created by the AD FS server.