WS-Trust: Interoperable Security for Web Services

Introduction

Karl Marx was probably not referring to web services security when he wrote "From each, according to his ability; to each, according to his need." If he had been, he would have been advocating an architecture in which all entities in a web services transaction would be able to make their own choices for the security characteristics they would expect of incoming SOAP messages (the "to each according to his need" part), as well as for the security mechanisms they would apply to outgoing SOAP messages (the "from each according to his ability" part). It sounds like an interoperability nightmare. If every company were to define their own policies for what a "secure" SOAP message was, in isolation from the practices and capabilities of the partners/customers they wished to do business with, the chances of any two parties being able to find an intersection between requirements and capabilities would seem vanishingly small, making interoperable security impossible.

Nevertheless, the emerging WS-Security standard for securing web services at the message layer (currently progressing towards standardization within OASIS), if applied in isolation, leads to just this sort of interoperability barrier. A SOAP client could apply arbitrary security operations (e.g. signing and encryption) to their messages in a manner fully conformant with the WS-Security specifications and the recipient SOAP Service could still be unable to validate, extract, and or process the message if its security infrastructure was not compatible with that of the client.

WS-Security will standardize how security information is added to SOAP messages. One important class of such security information is one which WS-Security calls Security Tokens -- a security token is "a collection of claims" about the sender (the sender typically proving their right to this claim through a digital signature). A fundamental issue that WS-Security neither address nor attempted to address is how two entities (a SOAP client and SOAP Service) can agree on the nature and characteristics of the security tokens that are the underpinning of WS-Security. WS-Security begins with the assumption that, if one of the parties uses a particular type of security token within the WS-Security header, then the other party will be able to interpret and process this token.

However, there are multiple viable formats for security tokens (e.g. X.509 certificates, Kerberos tickets, SAML Assertions, XACML policies, etc.), and it is unlikely that an arbitrary SOAP endpoint will be expected to understand each of these options. Consequently, there is no guarantee that there will be an intersection between the sets of supported security token formats of two different SOAP actors who wish to use WS-Security to secure their SOAP messages. This is of course not a limitation of WS-Security; it simply reflects the heterogeneity of the security environments between which WS-Security must operate.

Therefore, interoperable application of WS-Security across security domains with different security infrastructures will require either mechanisms by which actors can come to an agreement on the nature of security token they will use in any subsequent SOAP transactions, or mechanisms by which different security tokens can be mapped into others, such that individual SOAP actors can be guaranteed to receive only security tokens that they will be able to understand and process. Fortunately, the larger framework for securing web services, of which WS-Security is a part, defines additional components that will support both scenarios for addressing this interoperability issue. I mean WS-SecurityPolicy and WS-Trust respectively.

• WS-SecurityPolicy (released for industry review in December 2002, but not yet submitted to a standards body) specifies how web services actors can assert to potential transaction partners their policies with respect to WS-Security mechanisms, including their capabilitities and preferences with respect to security tokens (e.g. a SOAP service can assert "I can process X.509 certificates and SAML assertions but my first choice is SAML').

• WS-Trust is a proposal (released at the same time as WS-SecurityPolicy) that enables security token interoperability by defining a request/response protocol by which SOAP actors can request of some trusted authority that a particular security token be exchanged for another.

The remainder of this article provides an overview of the WS-Trust proposal and presents an example scenario to demonstrate the interplay between WS-Trust and WS-Security.

Note: Bilal Siddiqui provides a thorough overview of WS-Security in Web Services Security, Part 2 -- please refer to that article for the details of how WS-Security enables message level security through XML Signatures and XML Encryption.

WS-Trust Overview

As its name suggests, WS-Trust is motivated by more than enabling interoperability between the multiple formats for security tokens that might be used in a WS-Security protected message. It also addresses the issue of trust interoperability. Even if a given security token's format is acceptable to a recipient of a WS-Security-protected SOAP message, interoperability at the syntax level is no guarantee that the recipient will be able to trust the token. For example, for a SOAP Service to support Kerberos tokens does not mean that it would be able to accept Kerberos tickets from arbitrary Kerberos Key Distribution Centers -- the service would not have the necessary trust (in the form of shared symmetric keys) with these KDCs in order to decrypt and verify such tickets.

In principle, the recipient of a WS-Security-protected SOAP message will have three potential issues with the security token contained within the Security header:

1. format -- the recipient may find the format or syntax of the token incomprehensible. For instance, the incoming security token may be a Kerberos ticket and the recipient does not have the necessary Kerberos functionality in order to parse and interpret this binary token. Other recipients might find an X.509 certificate equally cryptic.

2. trust -- the recipient may be unable to build a chain-of-trust from its own trust anchors (e.g. its X.509 Certificate Authority, a local Kerberos KDC, or a SAML Authority) to the issuer or signer of the token.

3. namespace -- the recipient may be unable to directly comprehend the set of claims within the token because of syntactical differences. For instance, a SAML Attribute assertion might assert that the sender has the role of "Purchasing Officer" whilst the recipient's authorization policies are expressed in terms of "ProcurementAdmin." While these roles may "mean" the same thing (i.e. "the subject is authorized to place orders up to $5,000 in a 24 hour period"), the difference in syntax would prevent appropriate processing.

WS-Trust addresses all three of these potential interoperability issues by defining a simple request/response for security token exchange. A client sends a RequestSecurityToken to a Security Token Service, the request includes the security token that the client is asking to be exchanged. The Security Token Service (STS) responds back with a RequestSecurityTokenResponse that contains the new token. The three interoperability issues identified above can be addressed through this exchange as follows:

1. format -- the returned token is in a format understandable by the recipient

2. trust -- the returned token will be signed by the STS; it is expected that the recipient and the STS will have an established trust relationship such that the recipient will be able to verify and trust the new token.

3. namespace -- the STS will ensure that the returned token will use syntax appropriate to the expectations of the recipient.

In addition to token exchange, the WS-Trust request/response protocol is general enough to support token issuance (the client presents a claim to the STS for the STS to authorize through the issuance of a corresponding security token) and token validation (the client presents a token to the STS and asks that its validity be determined.) Issuance and validation can be thought of as special cases of exchange, as both the client claim in the issuance case and the STS validity assertion response in the validation case can be thought of as tokens. The different applications of WS-Trust are shown below:

Figure 2. WS-Trust applications.

The token exchange, issuance, and validation applications have analogies in existing security technologies. In X.509 a subject presents their claimed identity along with supporting evidence to a Registration Authority which, after verification, requests of a Certificate Authority that a certificate be issued. Likewise, in Kerberos, a client authenticates to the Key Distribution Center in order to be granted a Ticket Granting Ticket (an issuance) that the client will subsequently use to request a new ticket targeted for a particular service (an exchange).

For the X.509 world, there already exists a proposal for XML-based token issuance and token validation, namely, the X-KRSS and X-KISS components of the XML Key Management Specification (XKMS) currently being standardized under the W3C. It remains to be seen how WS-Trust and XKMS will compete, cooperate, or coexist in this area.

Pages: 1, 2

Next Page