Prior to Having Secure Communications... - Security

Prior to having secure communications, each party needs to determine whether it can "trust" the asserted credentials of the other party. WS-Trust defines extensions to WS-Security that provide

• Methods for issuing and exchanging security tokens

• Ways to establish and access the presence of trust relationships

Similar to SAML, WS-Trust defines a request/response mechanism for obtaining security tokens.

The most important attributes of WS-Trust to understand are

• The relationships between Web service requestor, Web service provider, and the Security Token Service (STS), as shown in Figure 9.3

• These two methods: <RequestSecurityToken> and <RequestSecurityTokenResponse>

Security Token Services form the basis of trust by issuing security tokens that can be used to broker trust relationships between different trust domains. As Figure 9.3 shows, a Security Token Service is a trust broker ready and willing to provide a Web service with a way to determine whether it will trust an incoming request from a different (possibly unknown) trust domain. A policy statement at the Web service provider notifies the Web service requestor that a security token is required for use of this service. The requestor provides such a token, either having obtained it previously or by the requestor now sending a <RequestSecurityToken> to the Security Token Service. The so-obtained WS-Security–compatible security token is then provided when requesting service from the Web service provider. WS-Trust also provides for a challenge-response protocol for the Web service provider to strongly validate the efficacy and timeliness of the requestor's security token.

Figure 9.3 The WS-Trust model for providing a Security
Token Service trust broker in support of WS-Security.

The Web service security model defined in WS-Trust is based on a process in which a Web service can require that an incoming message prove a set of claims (for example, name, key, permission, capability, and so forth). If a message arrives without having the required proof of claims, the service ignores or rejects the message outright. A service can indicate its required claims and related information in its policy as described by the WS-Policy and WS-PolicyAttachment specifications described in detail in Chapter 8.

A requestor can send messages that demonstrate its ability to prove a required set of claims by associating security tokens with the messages and including message signatures that demonstrate proof of possession of (the contents of) the tokens.

If the requestor does not have the necessary token or tokens to prove the claim, it contacts a Security Token Service and obtains the tokens. These "authorities" may, in turn, require their own set of claims.

The WS-Trust model illustrated in Figure 9.3 shows that any requestor may also be a service and that the Security Token Service is itself a Web service, including expressing policy and requiring security tokens.

This general messaging model—claims, policies, and security tokens—subsumes and supports several more specific models, such as identity-based security, access control lists, and capabilities-based security. It allows use of existing technologies such as X.509 public key certificates, XML-based tokens, Kerberos shared-secret tickets, and even passwords. The general model, in combination with the WS-Security and WS-Policy primitives, is sufficient to construct higher-level key exchange, authentication, policy-based access decisions, auditing, and complex trust relationships.

A quick overview of the WS-Trust model is that a Web service has a policy applied to it, receives a message from a requestor that possibly includes security tokens, and may have some protection applied to it using WS-Security mechanisms. The following steps are performed by the trust engine of a Web service:

1. Verify that the claims in the requestor's security token are sufficient to comply with the provider's policy and that the message conforms to this policy.

2. Verify that the attributes of the claimant are proven by the signatures. In brokered trust models, the signature may not verify the identity of the claimant; it may verify the identity of the intermediary, who may simply assert the identity of the claimant. The claims are either proven or not based on policy.

3. Verify that the issuers of the security tokens (including all related and ancestral security tokens) are trusted to issue the claims they have made. The trust engine may need to send tokens to a Security Token Service to exchange them for other security tokens that it can use directly in its evaluation.

If these conditions are met, and the requestor is authorized to perform the operation, the service can process the service request within the specified trust model just described.