Trust Networks in a Web Services World

Introduction

Security token services (STS) make trust networks scalable by mediating trust between companies that would otherwise not be able to ascribe trust to another. Rather than maintaining pairwise trust with all potential partners, individual companies instead form a trust relationship with the STS and then rely on the STS to form sufficient other trust relationships such that the necessary indirect trust can be established. Based on the trust that a company places in the STS, it may choose to extend trust to another company in which the STS places its confidence.

This prompts the question of how a company comes to place trust in an STS. Since companies will trust other companies based on their trust in these authorities, the decision to trust an STS is significant. So how does a company make this decision? What questions might it ask of the STS before choosing to trust it? This article examines these issues.

Trust through Assertions

Web services security means ensuring that the origin, integrity, and confidentiality of SOAP messages can be guaranteed to some level of confidence. These security properties are enabled through processing of the message contents using cryptographic keys associated with the actors involved. This association is accomplished by binding together the key and some characteristic of an actor (e.g. identity, authorizations, attributes) within a security token.

Trust between entities in many web services transactions is enabled by a separate authority issuing security tokens (e.g. X.509 certificates, SAML assertions, Kerberos tickets, etc.) regarding the identity or other characteristics of the actors involved. Recipients are typically able to ascribe a sufficient level of trust in a security token because they can be confident of its origin, i.e. they know and trust the authority that issued the token and can verify through cryptographic means that the token was issued by that authority. It is through the existing trust they have in the third party security token issuer that they are able to derive indirect trust in the holder of a security token created by that issuer.

The following sections present different examples of how trust between entities can be facilitated through the involvement of a third party authority issuing assertions. While the nature of the assertion varies in each case, we'll see that the trust models are the same.

SAML Authentication Authority

A Single Sign-On (SSO) system is one in which a user authenticates to a single entity and then, based on that authentication, is automatically logged-in at other resources they will subsequently try to access. SSO typically entails the entity that originally authenticated the user creating an assertion to that effect and communicating that assertion to the subsequent resources at which the user attempts to access protected resources. For SSO on the Web, SAML (Security Assertions Markup Language) standardizes both the XML structure of this assertion as well as a request-response protocol for communicating the assertion between sites. The Liberty Alliance bases its framework for federated identity on SAML, extending the SAML assertions and protocols to better support real-world scenarios of federated identity.

Subsequent sites or applications log treat the user as having been authenticated, without requiring the user to explicitly authenticate again as they would normally require. They are willing to do so because the SAML authentication assertion attests to the fact that the user did indeed authenticate at the first site within a certain period of time. Since subsequent sites can be confident of the origin and integrity of the SAML assertion, and because of the confidence it has that the first web site will only create such an assertion after the user actually did authenticate to it, subsequent sites can be confident that the user is indeed the individual whose identity is asserted to in the SAML assertion.

WS-Trust Security Token Service

For web service clients, as opposed to individual web users, SSO is not a concern. A SOAP client will not forget its "password" and will not balk at authenticating repeatedly. However, for SOAP clients a sequence of events comparable to SAML SSO is still relevant as a mechanism for brokering trust rather than convenience.

A SOAP client, engaging in some secure transaction with an arbitrary service provider, will need, first, to go to some third party authority because, by default, there would likely be no trust relationship between itself and the service provider. However, if there were trust between the client and some third party authority, and between the third party and the service provider, then indirect trust can be established between the client and the provider, enabling the desired business transaction.

WS-Trust is a proposal (primarily from IBM and Microsoft) that defines how the client and third party would communicate in order to enable subsequent secure and trusted communication between the client and the provider. The SOAP client would send a message to the WS-Trust Security Token Service (STS) requesting that the STS issue it a token which, when subsequently presented to the service provider by the client (as part of the actual business transaction), will allow the provider to place sufficient trust in the (theoretically previously unknown) client to proceed with the transaction. The trust that the provider has in the STS allows it to assign trust to the tokens issued by that STS and, consequently, to the SOAP clients to which the tokens are issued.

Note that although SAML was described in the context of a browser SSO scenario, and WS-Trust in the context of a SOAP transaction, neither are restricted to this application and can be used in either case. Indeed, the Liberty Alliance's ID-Web Services Framework uses SAML in the manner described for WS-Trust and WS-Federation (another IBM, Microsoft proposal) profiles how WS-Trust can be applied to the browser SSO case.

X.509 Certification Authority

An X.509 certificate is an assertion that cryptographically binds together some entity's identity (e.g. a user's name or an SSL server's IP address) with a public key. By proving that they are in possession of the private key associated with the public key contained within, the user can lay claim to the asserted identity when they present the certificate to some other party in the context of an transaction.

Anybody can create a certificate, for their own use, in which they could claim any identity. Certificates will only be trusted (and thereby provide value) if a relying party can trust the issuer -- typically a trusted third party called a Certification Authority (CA). The relying party will either directly trust the issuing CA for a certificate presented to it, or may trust that CA because its own CA (that issued it a certificate) trusts that other CA.

Trust between certificate holders and relying parties is made possible by the potentially long chain of other trust relationships that exist between the two fundamental entities and their associated CAs. It is through the trust that relying parties have for CAs that they will be willing to ascribe trust to the subjects of certificates issued by those CAs or other CAs for which a chain of trust can be built.

The trust established through one mechanism can be the basis of trust for another mechanism. For instance, the trust established between two certificate holders based on their shared trust with the same X.509 CA could enable SAML-based SSO between them, as they would be able to verify and trust the digital signatures calculated over the SAML assertions.

Authority Recognition

An entity can be said to trust another entity when the first entity makes the assumption that the second entity will behave exactly as expected. According to this definition, the essence of trust lies in the disappointment of a trusting party's reasonable expectation of another's behaviour. Trust then is dependent on each actor being confident that the other actors will behave in the prescribed manner for specific circumstances; and, importantly, the protections afforded to those impacted parties should another not perform as expected.

Since an entity, in trusting an authority, will consequently assign trust to other entities certified by that authority, the trust that an entity has in an authority will be based on its expectation that the authority will only place its own trust in valid entities.

However, in determining whether or not to trust a particular STS for a given context, a relying party will likely require more information than simply the STS's assertion that it will issue tokens only to valid entities. The details matter. Consequently, the STS should be able to provide to a potential relying party sufficient information to faciliate the decision of whether or not to recognize the authority. It is from the information that the STS makes available that an entity will, at least partially, base its expectations, and consequently its trust, in that STS.

The nature of this information can vary. Ultimately, the question a relying party faces in determining whether or not to trust an STS and recognize the tokens it issues as valid for a particular application is -- Knowing what I know about the authority and other participants, is such a token appropriate for the application for which I intend to use it?

Critical in this query is the fact that a relying party's decision to recognize an authority will almost certainly not be a simple binary yes or no choice, applicable to all applications for which that authority's assertions might be used. More likely is that the trust will be qualified to particular applications. For instance, the result of the relying party's decision to recognize a particular authority might be the policy "Accept all signed SAML attribute assertions from this authority if the total value of the transaction in question is less than $1000."

What the relying party "knows" about the authority can take different forms, distinguished by the nature of the information that the STS makes available to potential relying parties -- The authority asserts that its processes and practices under which this type of token is issued are as follows...

An example of this category of information is the Certification Practices Statement (CPS), by which an X.509 Certification Authority advertises the details of the processes through which it issues certificates. An example of a CPS is available here. Another example is the Liberty Alliance's Authentication Context mechanism by which an Identity Provider describes the details underlying the SAML assertion issuance enabling SSO. This model primarily places the burden of parsing the details of the STS's processes (and understanding their significance) on the relying party -- The authority asserts its business-level commitments with respect to the token along with the obligations assumed by any entity which uses the token.

An example of this class of information is a Certificate Policy statement by which an X.509 Certificate Authority lists the applications for which a certificate is approved and may limit its liability with respect to use of those certificates. Important to note is that, in this model, the details of the "processes and practices" are not provided. Instead the STS defines the degree to which it will stand behind the tokens it issues. This model shifts some of the risk analysis burden off the relying party by elevating the decision. -- The authority asserts that their business-level commitments with respect to the token along with the obligations assumed by any entity who uses the token are such that the token is appropriate for a particular application.

This model places the burden of risk analysis squarely on the shoulders of the STS, but also implies that the STS is aware of the applications for which its tokens will be used. This last would preclude this model for remote authorities "in the sky" that are necessarily ignorant of the applications for which their assertions are used.

Perhaps more critical than the particular nature of the information is the fact that, as yet, within the emerging web services security architecture, there is neither a standard syntax nor distribution mechanism by which an authority would make this information available for consumption by potential relying parties. There is however work underway in this area. The Global Grid Forum's Authority Recognition Research Group (ARRG) is exploring the potential for simple, inexpensive, semi-automatable mechanisms by which an authority can publish this information and by which a relying party will make its trust decision.

Summary

Secure web services will build on the network of direct and indirect trust relationships in which individual businesses participate. A key role in this trust network are security token services, which enable trust to be established between two entities desiring to engage in some SOAP transaction. The trust that a business entity will have in an STS will therefore be key, and it will be based on the expectations that that business will have for the behavior of the STS.

Although mechanisms currently exist by which the STS can advertise the necessary information to potential relying parties, they are not designed to support the sort of dynamic relationships made possible by web services. Fortunately, work is underway to define new mechanisms to simplify and facilitate connecting with the STS hubs.