RE: [soa-rm-ra] WS Trust

In case it helps, here is an excerpt from a March 2003 article that I wrote on WS-Trust - though the spec has changed since then, I think if you look at the description I provided below, most if not all of the concepts can be applied to the figure that Duane provided. The figure below is my own, as there was no such figure in WS-Trust at the time.

Joe

P.S. My other choice was to send you a very short block of Word Art with the word "voiceover".;)

Managing Trust Relationships: WS-Trust

All of the concepts discussed to this point are highly important, but they cannot be useful unless there is a trust relationship between two parties. This is the focus of WS-Trust specification, released in December by 2002 by Microsoft, IBM, Verisign, and RSA Security.

Trust Engine/Security Token Service

WS-Trust introduces the notion of a trust engine, a conceptual component of a Web service that evaluates the security-related aspects of a message. A trust engine verifies that:

The claims in a security token are sufficient to comply with the policy and that the message conforms to the policy.
The attributes of the claimant are proven by the signatures.
The issuers of the security tokens are trusted to issue the claims they have made.

For example, if a policy stated that only Kerberos tickets were accepted as a security token, the trust engine of a Web service would enforce this requirement for all incoming messages. The WS-Trust specification also introduces the notion of a security token service that issues security tokens based on trust, similar to a certificate authority (CA).

The figure below depicts a "sender" and "receiver" Web service, each with its own trust engine. A security token service is also depicted, from which the sender Web service will request a security token to be used for its interaction with the receiver Web service. The sender Web service can request a security token based on the receiver Web service's policies, using the mechanisms described earlier in this article. The sender Web service will use its trust engine to authenticate the security token service, while the receiver Web service will use its trust engine to authenticate the sender Web service.

XML Example: Security Token Request/Response

The following example demonstrates a request for a security token (X.509 certificate), and the response with the certificate. The <wsse:BinarySecurityToken> was seen earlier in the description of the WS-Security specification.

<wsse:RequestSecurityToken>
  <wsse:TokenType>wsse:X509v3</wsse:TokenType>
  <wsse:RequestType>wsse:ReqIssue</wsse:RequestType>
</wsse:RequestSecurityToken>

<wsse:RequestSecurityTokenResponse>
  <wsse:RequestedSecurityToken>
    <BinarySecurityToken ValueType="wsse:X509v3"
                         EncodingType="wsse:Base64Binary">
                         MIIEZzCCA9CgAwIBAgIQEmtJZc0...
    </BinarySecurityToken>
  </wsse:RequestedSecurityToken>
</wsse:RequestSecurityTokenResponse>

In the above example, the <wsse:RequestType> element value of "ReqIssue" denotes the issuance of a security token. Other valid values are "ReqValidate" (validate security token) and "ReqExchange" (exchange security token).

Challenges

In some cases, a security token service may choose to challenge the requestor of a security token. For example, this may occur if the security token service does not trust the nonce and timestamp (for example, the freshness) in the message. Or, the security token service may challenge the signature within the message. Challenge requests and responses are issued by specifying challenge and response elements within a <wsse:RequestSecurityTokenResponse> element, in a negotiation-type scenario.

XML Example: Signature Challenge

Signature challenges are processed using the <wsse:SignChallenge> element, as shown in the following example:

<wsse:SignChallenge>
  <wsse:Challenge>Describes the message parts to be
                  signed...</wsse:Challenge>
  <wsse:SecurityTokenReference>...</wsse:SecurityTokenReference>
</wsse:SignChallenge>

The <wsse:Challenge> element in the above example uses one of two possible mechanisms to describe the message parts to be signed: either an XPath expression, or one of several "message part selection functions" that are defined in the WS-PolicyAssertions specification. The <wsse:SecurityTokenReference> element is used to reference security tokens that are passed as part of the negotiation process. Once the sender receives this challenge, they would normally create a new signature that includes the specified message parts and return the new signature in a <wsse:SignChallengeResponse> element.

Specification Location

The WS-Trust specification can be found at http://msdn.microsoft.com/ws/2002/12/ws-trust.