Section 13.1. WS-Trust


13.1. WS-Trust

WS-Security messages contain security tokens, which a requester can obtain in many ways. The requester might have a username and password or possess an X590 certificate, which allows the requester (or application) to form a security token. These ad hoc approaches work in many cases, but more sophisticated multiparty scenarios might require a more flexible model.

Consider the example from the previous chapter. How does a traveling user, as an employee of CompanyABC, get a valid token for access to Fabrikam456 travel? He might have a logon username and password to Fabrikam456, but this would be as a private individual. The user might also have an X509 certificate, but this does not prove employment by CompanyABC.

CompanyABC might replicate their employee directories and provide them to Fabrikam456, but this is expensive. It also discloses a significant amount of private information. An alternate approach is to set up a limited trust relationship between the security systems of CompanyABC and Fabrikam456. CompanyABC's security infrastructure can issue security tokens that Fabrikam456 accepts. WS-Trust is an extensible specification to support this scenario and more complex models.

WS-Trust defines a conceptual model for using a Web service. A requester examines the WS-SecurityPolicy statements associated with a Web service. The policy statements specify the type and authority of security tokens that the Web service requires for messages it processes. If the requester does not possess acceptable tokens, it must obtain them. One way is to contact a security token server (STS) that the Web service's policy statements identify as acceptable.

A security token service (STS) is a Web service that has a WSDL interface and processes secure SOAP messages. An STS issues, renews, and validates security tokens. Consider again the example from the previous chapter.

  1. The traveling user's application sends a RequestSecurityToken (RST) message to the STS interface of CompanyABC's security infrastructure. This message requests a security token that applies to Fabrikam456. The RST message itself contains a security token that authenticates the requester to CompanyABC. CompanyABC's STS might require additional signature information and encryption on the request.

  2. If satisfied, CompanyABC responds with a RequestSecurityTokenResponse message that contains the security token that the traveling user submits to Fabrikam456. The response might contain additional information, such as the lifetime of the token and proof-of-possession data. It might also contain key information, which allows the requester to compute a key. WS-Trust supports an extensible set of models for issuing keys or information that allow a requester and an STS to derive keys.

  3. The traveling user's application uses the returned token on messages it sends to Fabrikam456. The application uses any keys that are provided or derived to properly encrypt and sign information in the message and header, to comply with Fabrikam456's security policies.

  4. Fabrikam456 validates that the incoming message complies with its security policies. For example, Fabrikam456 might verify that the security token has been signed by CompanyABC using an X509 certificate issued by WellKnownSecurityService.

RequestSecurityToken and RequestSecurityTokenResponse are the messages that define the interface to an STS. These are abstract, base messages. WS-Trust defines a set of bindings that associate concrete semantics and extensions to the messages. For each binding, WS-Trust documents a set of WS-Addressing Action URIs that define the semantics. WS-Trust also introduces a <RequestType> element that takes a URI value to define the semantics of the message. WS-Trust defines the following bindings:

  • Issuance Based on the security token in the request, a new token is issued.

  • Renewal Renew a token.

  • Validation Validate a token.

 <wst:RequestSecurityToken>        <wst:TokenType>...</wst:TokenType>        <wst:RequestType>...</wst:RequestType>        <wst:Base>...</wst:Base>        <wst:Supporting>...</wst:Supporting>               ...        <wsp:AppliesTo>...</wsp:AppliesTo>        <wst:Claims Dialect="...">...</wst:Claims>        <wst:Entropy>               <wst:BinarySecret>...<wst:BinarySecret>        </wst:Entropy>        <wst:Lifetime>               <wsu:Created>...</wsu:Created>               <wsu:Expires>...</wsu:Expires>        </wst:Lifetime> </wst:RequestSecurityToken> 

The preceding code snippet provides an overview of the elements in a Request Security Token (RST) message. TokenType identifies the type of token requested. An STS might return many types of tokens. RequestType specifies the binding, that is, issuance, renewal, or verification. Base is the security token the requester is using to obtain the new security token. AppliesTo is the Web service, specified by a WS-Addressing endpoint reference, for which the requester wants a security token. Entropy allows the requester and the STS to exchange information for deriving keys. The WS-Trust specification provides more details on the elements of the RST and Request Security Token Response (RSTR) messages.

In addition to AppliesTo, WS-Trust allows one Web service to request a security token on behalf of another. The requester can specify the endpoint reference of the service on whose behalf it is requesting the token. Consider the traveling CompanyABC employee. The contract between CompanyABC and Fabrikam456 might require CompanyABC's STS to contact Fabrikam456's to obtain a token. CompanyABC would obtain the security token on behalf of the requesting applications.

WS-Trust also defines a model for challenges. Upon receiving a message with a security token in it, a service might send a challenge, forcing the requester to demonstrate its right to use the token. If the requester passes an X509 certificate, the service might respond with a challenge that contains some random data. The requester must sign the random data with the private key associated with the certificate, demonstrating proof of possession. The challenge model strengthens security by eliminating some attacks.

WS-Trust provides support for specifying key sizes and algorithms in the request and response messages. The specification also provides support for passing policy information in messages.

Each Web service endpoint logically implements a trust engine that must understand the WS-Security and WS-Trust model. The trust engine of a Web service must verify the following:

  • The security token is sufficient to comply with the Web service's policy, and the message conforms to the policy (for example, the necessary elements are encrypted or signed).

  • The security tokens are proven signatures.

  • The issuers of the security tokens (including all related and ancestral security tokens) are trusted by this site to issue the claims they have made.

The trust engine might need to send tokens to a security token service to exchange them for other security tokens, which it can use directly in its evaluation. If the trust engine determines that the conditions are met and the requester is authorized to perform the operation, the Web service can process the Web service request within the aforementioned trust model.

There are many ways to assert trust, and two methods of assessing the presence of a trust relationship. WS-Trust describes these two methods, which depend on whether the assessment is based on information from within a message flow (in-band) or outside it (out-of-band).

13.1.1. In-Band

As part of a message flow, a security token service might be asked to exchange a security token (or some proof) of one form for another. This exchange request is made either by a requester or by another party on the requester's behalf:

  • If the security token service trusts the provided security token (for example, it might trust the token's issuing authority), and the request can prove possession of that security token, the exchange is processed by the security token service. This is an example of an in-band direct trust relationship.

  • In the case of a delegated request, in which another party provides the request on behalf of the requester, the security token service generating the new token might not need to trust the authority that issued the original token because it trusts the security token service making the request. The basis of the trust is the relationship between the two security token services.

13.1.2. Out-of-Band

An administrator or other trusted authority can designate that all tokens of a certain type are trusted. The security token service maintains this as a trust axiom and may send it to trust engines so they can make their own trust decisions (or revoke it later). Alternatively, the security token service might provide this function as a service to trusting services.



    Web Services Platform Architecture(c) SOAP, WSDL, WS-Policy, WS-Addressing, WS-BP[.  .. ] More
    Web Services Platform Architecture(c) SOAP, WSDL, WS-Policy, WS-Addressing, WS-BP[. .. ] More
    ISBN: N/A
    EAN: N/A
    Year: 2005
    Pages: 176

    flylib.com © 2008-2017.
    If you may any questions please contact us: flylib@qtcs.net