WS-* Security Specifications for Integration - Security

Integration, in the context of Web Services Security, is the federation of identities and uniform authorization policies. Federation is the integration of trust domains across organizational boundaries and is addressed by WS-Federation. Authorization is the unification of access control policies across organizational boundaries and is addressed by WS-Authorization.

WS-Federation enables the establishment of federated trust using WS-Security, WS-Policy, WS-Trust, and WS-SecureConversation as composable building blocks. Federation in this context means that a group of organizations that will have communicating Web services agrees on a uniform set of standards and policies about identification and authentication of entities for the purpose of translating one entity's security tokens into another type of security token. For example, WS-Federation solves the problem of one organization using Kerberos and the other with which it wants to communicate using X.509. WS-Policy and WS-Trust are used to determine which tokens are consumed and how to apply for tokens from an external service.

Figure 9.4 illustrates one way the WS-Trust model may be applied to simple federation scenarios. Here, security tokens (1) from the requestor's trust realm are used to acquire security tokens from the resource's trust realm (2) to access the resource/service (3). That is, a token from one Security Token Service (STS) is exchanged for another at a second STS (or possibly stamped or cross-certified by a second STS).

Next, Figure 9.5 shows the detailed sequence of steps used to exchange security tokens between a requestor Web service and the Web service provider resource.

Figure 9.4  Simple federation scenario allowing requestor in one trust domain to interact with a resource in a different trust domain using different security models.

Figure 9.5  Eight-step process used in WS-Federation to cross different trust domains with a security token.

This process is as follows:

1. Acquire policy.

   If the requestor doesn't already have the policy for the service, it can obtain the policy using the mechanisms defined in WS-MetadataExchange. WS-MetadataExchange allows a service to directly obtain information using WSDL, or it may choose to use a UDDI service that aggregates this information for multiple target services.

2. Return policy.

   The requested policy is returned using the mechanisms defined in WS-MetadataExchange.

3. Request security token.

   The requestor requests a security token from its IP/STS (assuming short-lived security tokens) using the mechanisms defined in WS-Trust: <RequestSecurityToken>.

4. Issue security token.

   The IP/STS returns a security token (and optional proof-of-possession information) using the mechanisms defined in WS-Trust: <RequestSecurityTokenResponse> and <RequestedProofToken>.

5. Request security token.

   The requestor requests a security token from the Web services IP/STS for the target Web service using the mechanisms defined in WS-Trust: <RequestSecurityToken>. Note that this is determined via policy or some out-of-band mechanism.

6. Return security token.

   The Web service's IP/STS returns a token (and optionally proof-of-possession information) using the mechanisms defined in WS-Trust: <RequestSecurityTokenResponse>.

7. Send secured request.

   The requestor sends the request to the service attaching and securing the message using the issued tokens as described in WS-Security.

8. Return result.

   The service issues a secured reply using its security token.

---

WS-Federation, SAML, Liberty, and Passport - WS-Federation deals with identity in a federated Web services context. As of this writing, no specification has been published for WS-Federation, and it is not without controversy due to the Microsoft name on the specification and the questions around the Sun-sponsored Liberty Alliance project and the Microsoft-owned Passport technology.

WS-Federation is working toward compatibility with SAML as SAML tokens become one of the types of federated tokens accepted, along with X.509, Kerberos, and XrML.

That being said, it seems valuable to have a standard approach for federated trust scenarios specific to Web services that is independent of the Liberty Alliance and Passport and generalized enough to fit into both models of identity federation.

At the very least, WS-Federation addresses a really difficult unsolved problem: how to get a Web service based in a domain using Kerberos to work effectively in a trusted fashion with a Web service based in an X.509 domain.

---

WS-Authorization

WS-Authorization deals with authorization decisions in the context of Web services. It describes how access policies for a Web service will be specified and managed. As of this writing, no specification has been published for WS-Authorization. Its objectives are similar to the eXtensible Access Control Markup Language (XACML) and will undoubtedly be heavily influenced by it.