Security tokens are used to provide an end-to-end security solution. These security tokens must be shared, either directly or indirectly, between the parties involved in message processing. Each party also must determine whether the credentials asserted in the token can be trusted. These trust relationships are based on the exchange and brokering of security tokens and in the supporting trust policies that have been established by the corresponding security authorities. How much of a brokered token is trusted, for example, is determined by system administrators and the trust relationships they have established.Services that provide security tokens can be quite varied. This is where each of the underlying security technologies is first used by a Web service. To provide a uniform solution irrespective of the security technology, new protocols were designed for security token exchange between trust domains.WS-Trust [WS-Trust] complements WS-Security with protocols for requesting, issuing, and brokering security tokens. In particular, operations to acquire, issue, renew, and validate security tokens are defined. Another feature introduced in the specification is a mechanism to broker new trust relationships. Network and transport protection mechanisms such as IPsec or TLS/SSL can be used in conjunction with WS-Trust for different security requirements and scenarios. The service that issues security tokens is called a Security Token Service.Security token acquisition can be done directly by explicitly requesting one from an appropriate issuer, as shown in Figure 4-1, or indirectly by delegating the acquisition to a trusted third party. Tokens can also be acquired out-of-band. For example, the token can be sent from a security authority to a party without the token having been explicitly requested. In general, when a Web service cannot provide all the necessary security assertions for a successful interaction, it has to request additional security tokens.
The main protocol defined in WS-Trust is an asynchronous request/response pair used for requesting and obtaining a security token. The requestor can specify the token type and the request type in each request operation. The three initial request types defined represent issuing, validating, and exchanging security tokens. The response message contains information, when appropriate, about the key type used in the token, its length, a scope to which the security token applies, and the security token itself. The specification also uses a mechanism to reference security tokens in those situations when it is advisable to return a security token as part of the security header defined in WS-Security and not in the request security token response message defined in WS-Trust.WS-Trust also defines extensions to the "request security token" operation to denote delegation, forwarding, and proxy requirements on the requested security token(s). These three extensions provide flexibility required for brokering situations. In addition, three token lifetime management extensions specify whether a token can be renewed, whether it is allowed to process requests for postdated tokens, and to specify the lifetime of a security token.To complete the trust relationships picture, system administrators determine initial trust relationships, designating, for example, a given service as a trusted root service. This approach is similar to what is used to bootstrap security on the Web today. All tokens obtained from this service are trusted to the same extent as the trusted root itself. For example, if a root is trusted for only claims A and B, and a message contains claims A, B and C, then only claims A and B in the message are trusted. Configuration flexibility is provided through trust relationship delegation.Security tokens expressing security claims are issued by a trusted root or through a delegation chain. These security claims are used to verify that the message complies with the security policies in place. They also verify that the attributes of the claimant are proven by the signatures. In brokered trust models, that is, those where a trusted intermediary dispenses security tokens, the signature could verify either the identity of the claimant or the identity of the intermediary. The intermediary might simply assert the identity of the claimant.To address scenarios in which a set of exchanges between the parties is required prior to returning, or issuing, a security token, mechanisms are specified for validation, negotiation, and exchange. A particular form of exchange called a "challenge" provides a mechanism for a party to prove that it possesses a secret associated with a token. Other types of exchanges include legacy protocol tunneling. WS-Trust defines how to extend the specification for additional token exchange protocols beyond these two examples.
لطفا منتظر باشید ...
