WIF Basic Principles (3) Security Token Service

The Security Token Service (STS) is a service component that is used to build, sign, and issue security tokens based on the Ws-trust and ws-federation protocols. It takes a lot of work to implement these protocols, but WIF can do all of this for you, making it easy for those who are not proficient in the protocol to start and run Sts. You can use cloud STS (such as LiveID STS), pre-built STS (such as ADFS 2.0), or if you want to issue custom tokens or provide custom authentication or authorization, you can use WIF to build a custom Sts. You can easily build your own STS with the help of wif.

STS Authentication supports multiple scenarios:

Q Isolate applications and services from the authentication mechanism so that they can focus on authorization-related declarations.

Q supports multiple credential types without complicating the implementation of applications and services.

Q supports federated scenarios, where users can gain access to resources in another domain by authenticating in their domain (by establishing a trust relationship between STS in a different domain).

Q simplifies the identity delegation scenario, and authenticated users gain access to downstream services.

Q simplifies declaration conversions so that relevant declarations can be used to authorize applications and services.

Any of these scenarios can be based on passive syndication (browser-based) or active syndication (windows-based clients). These scenarios are described in detail below, along with how to use the Geneva framework to build related logic in a custom Sts.

Active contact and passive joint

Before delving into the implementation of STS, review some basic knowledge. The STS used in the active Union is the implementation of the Ws-federation active requester profile and (main) Ws-trust specification.

At a higher level, Ws-trust uses four service operations to describe a convention: issuing, validating, renewing, and canceling. These actions are invoked by clients to request security tokens, to authenticate security tokens, to renew expired security tokens, and to cancel security tokens that should not be used again. According to the Ws-trust specification, each operation must send a message in the format of the Request Security token (RST) and return the message in the form of "rst response" (RSTR). In this section, assume that the issued token is the Security Declaration Markup Language SAML 1.1 or the SAML 2.0 token.

Figure 15-4 shows the core content of RST and RSTR when the active token is issued.

Figure 15-4 Token issuance of the active joint scheme

As shown in the figure, the RST message includes the necessary information required to request a security token, which concerns the type of token to be issued (SAML in this book), the claim requested by the "relying party" (RP) to be included in the issuance token, the related RP (appliesto) Information, including the URL and the certificate that is typically used to identify the RP, and the optional (not displayed) keying material that will be used for the RSTR return of the proof key.

If the token is successful, RSTR will include the issued SAML token and proof key (assuming that STS decides which proof key to use and must return it in RSTR). The SAML token will include the relevant declaration of the authenticated party, which protects the token from tampering by the STS signature, which contains the proof key for RP encryption, and it encrypts itself for the RP to ensure that only the target receiving node can process the token.

The client uses the certificate key to sign the message to the RP. The RP must be able to decrypt the proof key in the SAML token or reject the message. If the proof key in the token matches the signature in the message, it is proved that the call to the RP was sent by the caller requesting the token.

The passive federated scheme is based on the Ws-federation passive requester profile, which involves browser-based communication. Although the underlying messaging is still based on Ws-trust, the RST is decomposed into query string parameters in Stsurl, and RSTR is usually published as a form parameter to the RP. The passive STS and RP Use federated web handlers to intercept these parameters. The passive STS can either process the Ws-trust request directly or pass it to the underlying ws-trust implementation. Figure 15-5 illustrates how to handle RST and RSTR in a passive joint scenario.

Figure 15-5 Token issuance for a passive joint scheme