14.6 Web Services Security Model Principles

Web services can be accessed by sending SOAP messages to service end points identified by URIs, requesting specific actions, and receiving SOAP-message responses, including fault indications . Within this context, the broad goal of securing Web services breaks into the subsidiary goals of providing facilities for securing the integrity and confidentiality of the messages and for ensuring that the service acts only on requests in messages that express the claims required by policies.

Today, the SSL and TLS protocols are used to provide transport-level security for Web Services applications. These protocols offer several security features, including authentication, data integrity, and data confidentiality and enable point-to-point secure sessions. As a network-layer standard for transport security, IPSec may become important for Web Services. Like SSL and TLS, IPSec also provides secure sessions with application-level authentication, data integrity, and data confidentiality.

Today's Web Services application topologies include a broad combination of mobile devices, gateways, proxies, load balancers, DMZs, outsourced data centers, and globally distributed, dynamically configured systems (see Section 2.1 on page 23 and Section 6.2 on page 192). All these systems rely on the ability of message-processing intermediaries to forward messages. Specifically, the SOAP messaging model operates on logical end points that abstract the physical network and application infrastructure and therefore frequently incorporates a multihop topology with intermediate actors or roles.

When data is received and forwarded by an intermediary beyond the transport layer, both the integrity of data and any security information that flows with it may be lost. This forces any upstream message processors to rely on the security evaluations made by previous intermediaries and to completely trust their handling of the content of messages. The key point here is that sensitive information is transferred into the clear and is vulnerable to attackcombined with the fact that these intermediary systems are often edge processors, which makes them more susceptible to attack. Therefore, a comprehensive Web Services security architecture needs a mechanism that provides end-to-end security as opposed to point-to-point security. A comparison of these two approaches is shown in Figure 14.1. Successful Web Services security solutions will be able to leverage network-, transport-, and application-layer security mechanisms to provide a comprehensive suite of security capabilities.

Figure 14.1. Point-to-Point and End-to-End Configurations

The Web Services security model described herein enables us to achieve these goals by a process in which

• A Web service can require that an incoming message prove a set of claims. If a message arrives without having the required claims, the service may ignore or reject the message.

• A requester can send messages with proof of the required claims by associating security tokens with the messages. Thus, messages both demand a specific action and prove that their sender or sender's delegate has the claim to demand the action.

• When a requester does not have the required claims, the requester or someone on the requester's behalf can try to obtain the necessary claims by contacting other Web services. These security-token services may in turn require their own set of claims. Security-token services broker trust between trust domains by issuing security tokens.

This model is illustrated in Figure 14.2, showing that any requester may also be a service and that the security-token service may also fully be a Web service, including expressing policy and requiring security tokens.

Figure 14.2. Web Services Security Model

This general messaging security model claims, policies, and security tokenssubsumes and supports several more specific models, such as identity-based security, access-control lists, and capabilities-based security. The model allows use of existing technologies, such as X.509 public-key certificates, Kerberos shared-secret tickets, and even password digests, and provides an integrating abstraction allowing systems to build a bridge between security technologies. The general model is sufficient to construct higher-level key exchange, authentication, authorization, auditing, and trust mechanisms.

One of the security principles expressed in Figure 14.1 and introduced in WS-Security is the ability to provide an end-to-end propagation of a security context. This constitutes the goals and cornerstone for the Web Services security model shown in Figure 14.2. The set of the Web Services security specifications is shown in Table 14.1.

Table 14.1. Web Services Security Specifications

Layers	Specifications
Federation	WS-SecureConversation	WS-Federation	WS-Authorization
Policy	WS-Policy	WS-Trust	WS-Privacy
Security		WS-Security
Foundation		SOAP

WS-Security provides the basis for the other security specifications, including a comprehensive Web Services messaging security model as described in Table 14.1. Layered on this is a policy layer , which includes WS-Policy, the Web Services Trust Language specification (WS-Trust), and Web Services Privacy Language specification (WS-Privacy). Together, these initial specifications provide the foundation on which to establish comprehensive, secure, and interoperable Web services across trust domains.

Building on these initial specifications, the federation layer includes specifications for federated security , which includes a Web Services Secure Conversation Language specification (WS-SecureConversation), a Web Services Federation Language specification (WS-Federation), and a Web Services Authorization Language specification (WS-Authorization). The combination of these security specifications enables many scenarios (such as the one described in Section 14.8 on page 518) that would be difficult to implement with today's basic security mechanisms.

14.6.1 Web Services Message Security

A signed security token is asserted and cryptographically signed by a specific authority. For example, an X.509 certificate, which asserts a binding between one's identity and public key, is an example of a signed security token. Similarly, a Kerberos ticket represents a signed security token. Conversely, a user ID is an unsigned security token.

A SOAP header provides a mechanism for associating the signature with the claims in a security token. There are several things to note.

• Such a binding is limited to those elements covered by the signature.

• This mechanism does not specify a particular method for authentication; it simply indicates that security tokens may be bound to messages.

• The message recipient may or may not trust the security tokens or may trust them only partially.

• These security-model mechanisms are not a complete solution by themselves ; additional specifications are required for a complete security solution.

As we have observed , security-token claims can be either endorsed by an authority or left unendorsed. A set of endorsed claims is usually represented as a signed security token that is digitally signed or cryptographically protected by the authority. A security token can be pushed , or carried in a message, or the security token can be a reference that the receiver can use to pull the claim from the referenced authority.

Another aspect of a security model is the articulation of a trust relationship. Security tokens are useful within a trust domain. A trust domain can be articulated through a manual process, an agreement, or the implementation of a set of rules enforcing the trust policy. An unendorsed claim can thus be trusted given any established trusted channel between the sender and the receiver. For example, the unendorsed claim that the sender is Bob is sufficient for a certain receiver to believe that the sender is in fact Bob, if the sender and the receiver use a connection with a sufficient protection and there is a trusted channel between them (see page 522).

One special type of unendorsed claim is a proof-of-possession , data that is used in a proof process to demonstrate the sender's knowledge of information that should be known only to the claiming sender of a security token. Such a claim produces evidence that the sender has a particular piece of knowledge that is known to, or verifiable by, only appropriate actors. For example, a user ID and password pair is a security token with this type of claim. When a proof-of-possession is involved, the receiver decides whether the evidence produced is sufficient proof. This type of evidence is sometimes combined with other security tokens to prove the claims of the sender. Note that a digital signature applied to a message for the purposes of message integrity can also be interpreted as evidence of possession of part of the key pair, although in the WS-Security specification, a digital signature is not considered as a type of security token.

Protecting the message content from unauthorized access ( confidentiality ) and/or modification ( integrity ) are primary security concerns. The WS-Security specification provides a means to protect a message by encrypting and/or digitally signing the contents of the body or the header of the message.

• Message confidentiality leverages XML Encryption in conjunction with security tokens to keep portions of a SOAP message confidential. The encryption mechanisms are designed to support additional encryption processes and operations by multiple actors.

• Message integrity is provided by leveraging XML Signature in conjunction with security tokens to ensure that messages are transmitted without modifications. The integrity mechanisms are designed to support multiple signatures, potentially by multiple actors, and to be extensible to support additional signature formats.

14.6.2 WS-Policy

WS-Policy provides a general-purpose framework and corresponding syntax to describe and communicate the policies of a Web service. WS-Policy defines a base set of constructs that can be used and extended by other Web Services specifications to describe a broad range of service requirements, preferences, and capabilities.

The Web Services policy specification, detailed in Figure 14.3, includes

• The WS-Policy document, which defines the general grammar for expressing Web services policies

• The Web Services Policy Attachment specification (WS-PolicyAttachment) document, which defines how to attach these policies to Web services

• Two policy-assertion documents: the Web Services General Policy Assertions Language specification (WS-PolicyAssertions) and the Web Services Security Policy Language specification (WS-SecurityPolicy)

Figure 14.3. Set of WS-Policy Specifications

WS-Policy is designed to allow extensibility. Policy is a broad term that encompasses a range of disciplines, such as security, reliability, and privacy. Similarly, the ability to express policies is not limited to the expression of general policies or security policies. The set of WS-Policy specifications shown in Figure 14.3 adds another mechanism to the WS-Security portfolio, but policy expression is not limited to security policies. The intent is for the basic policy framework to accommodate the expression of domain-specific policy languages in a way that leverages domain knowledge within a consistent Web Services framework.

WS-PolicyAttachment offers several ways to advertise policy assertions for Web services. It builds on the existing WSDL and UDDI specifications but also supports extensibility. It allows for combining domain-specific policies with common policies for Web services. A typical example is a requesting Web service that may look for a service provider that offers processing in a particular human language, such as Italian. The requesting Web service thus applies a policy assertionthe need for Italian-language support. The provider could also make this assertion by advertising that it can offer its service in Italian. The WS-PolicyAssertions language offers this type of common policy expression by defining a generic set of policy assertions for Web services.

Security is a domain. To illustrate security policies, the WS-SecurityPolicy specification expresses assertions needed to support security tokens, integrity, and confidentiality as defined in WS-Security.

As we discuss in Section 14.6.3, in the Web Services paradigm, the trust between a service requester and a service provider is established through the exchange of information between the two parties in an expected and understood manner. The description of this expected behavior within the security space can be called a trust policy . The WS-Policy framework supports trust partners ' expressing and exchanging their statements of trust. Often, this expression of a broad level of trust between entities is built on the exchange of security tokens to provide the elements for a secure conversation.

14.6.3 WS-Trust

The WS-Trust specification starts the work of defining trust relationships by defining a set of interfaces for requesting security tokens. It is designed to support the creation of multiple security-token formats, as described in WS-Security, to accommodate a variety of security practices, including authentication, authorization, and secure conversations.

In general, a Web service has a policy applied to it, receives a message from a requester that possibly includes security tokens, and may have some protection applied to it using Web Services security mechanisms. For example, a Web service security configuration requires that the Web service requester provide an authorization token in order to access certain service enhancements. The authorization token might be generated by a security-token service, which takes in a proof of identity and a request for a signed claim that the named identity has a particular business certification. This authorization token can then be supplied in a request to the Web service, which has expressed trust in such a signed claim.

The trust engine of a Web service performs the following key steps:

1. Verifies that the claims in the token are sufficient to comply with the policy and that the message conforms to the policy.

2. Verifies that the claims are proved by the signatures, that is, performed with keys associated with the necessary attributes. In brokered trust models, the signature may verify the identity not of the claimant but of the intermediary, who may simply assert the identity of the claimant. The claims are either proved or not, based on policy.

3. Verifies that the issuers of the security tokens, including all related and ancestral security tokens, are trusted to issue the claims they have made. The trust engine may need to send tokens to a security-token service in order to exchange them for other security tokens it can use directly in its evaluation. This step may include token-signature hierarchy validation, performed by validating a CA chain (see Section 10.3.4 on page 372).

If these conditions are met and the requester is authorized to perform the operation, the Web service can process the Web service request within the specified trust model.

Asserting trust can be done in many ways, and assessing the presence of a trust relationship can be done by either of two methods. WS-Trust describes these two methods , which depend on whether the assessment is based on information from within a message flow ( in- band ) or external to a message flow ( out-of-band ).

1. In-band. As part of a message flow, a request may be made of a security-token service to exchange a security token, or some proof, of one form for another. The exchange request can be made either by a requester or by another party on the requester's behalf. The security-token service trusts the provided security tokenbecause, for example, it trusts the issuing authority of the provided security token, and if 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 one in which another party, the delegate , provides the request to a service on behalf of the requesterthe delegate may need to make a request to a security-token service to exchange the original token provided by the client for one that is acceptable to the target service. The exchanging security-token service may in turn submit a request to another security-token service to generate the new token. The generating security-token service may not need to directly trust the authority that issued the original token. In that case, the exchanging security-token service would trust the original token authority, and the generating security-token service would trust the exchanging security-token service.

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

14.6.4 WS-SecureConversation

WS-SecureConversation takes the designation of trust based on security tokens to the next level by demonstrating how tokens can be used within the context of these policy-defined trusted relationships to allow requesters and providers to securely exchange information over the duration of a conversation. Whereas WS-Trust defines the behavior of overall trust relationships, WS-SecureConversation focuses on defining a security contextsecurity tokenfor secure communications.

14.6.5 WS-Privacy

The purpose of WS-Privacy is to descibe the syntax and semantics for binding privacy policies to Web services and instances of data in messages. The main emphasis of WS-Privacy lies in enabling policies to be processed by Web service providers and requesters, in contrast to interfacing to human users on a precise meaning and on usability in chains of Web services within or across enterprises . WS-Privacy builds on WS-Policy and related standards. WS-Privacy does not define a new privacy-policy language but offers the means to bind such existing languages to a Web service.

14.6.6 WS-Federation

Federation is the overall term used to refer to the set of distinct, heterogeneous enterprises that wish to provide a user with a single-sign-on, ease-of-use experience. Enterprises can be corporate entities, Internet service providers, or associations of individuals. A federated environment differs from a traditional single-sign-on environment in that no preestablished rules limit how enterprises transfer information about a user. Policy rules may have been preestablished for an enterprise's participation in the federation. Within a federated environment, enterprises provide services that deal with authenticating users, accepting authentication assertions also referred to as authentication tokens supplied by other enterprises, and providing some form of translation of the identity of the vouched-for user into one that is understood within the local enterprise. Therefore, the goal of WS-Federation is to define mechanisms that are used to enable identity, attribute, authentication, and authorization federation across trust domains.

14.6.7 WS-Authorization

The purpose of WS-Authorization is to describe how access policies for a Web service are specified and managed. In particular, the goal is to describe how claims may be specified within security tokens and how these claims will be interpreted at the end point.

The goal of WS-Authorization is to be flexible and extensible with respect to both authorization format and authorization language. This enables the widest range of scenarios and ensures the long-term viability of the security framework.

14.6.8 Example

Let us use a travel agency scenario to illustrate some of these concepts. Fabrikam456 Travel Agency Company offers its travel services through several business portals to provide air, hotel, and car rental services to its customers. Fabrikam456 needs to establish trust relationships with its partners through these portals.

Fabrikam456 would like to offer an integrated set of services to its customers whereby a requester could submit a single request for hotel, airline, and vehicle. Fabrikam456 would like also the flexibility to extend the services for its partners on the basis of a variety of criteria: gold service, preferred customers, and so on. The policy for one of its partners, RentalCars456, might include a security policy requirement for a RentalCars456 security token to establish the user's identity, as well as a business application requirement stating the cancellation policy for reservations . The policy for another partner, UnitedCars456, might include a requirement for UnitedCars456 preferred-customer numbers .

Because Fabrikam456 supports various business relationships, it needs to be able to determine which travel services to invoke for which customer. How can the WS-Security standards help in automating the trust relationships for Fabrikam456 to quickly and securely offer integrated travel services as part of the customer's trusted portal environment?

Fabrikam456 could assume the registration tasks for all its partners and issue customers a Fabrikam456 user name and identifier. In this case, Fabrikam456 provides a veneer for its partners. Before a request is processed, Fabrikam456 checks the policy for a partnerfor example, RentalCars456notifies the user of the cancellation policy, and asks whether the request should be processed. Once approved, the request could be augmented by Fabrikam456 with additional security tokens, based on the user's identity, the privacy policy, and other business policies. For example, suppose that the user is an employee of a certain company, qualifies for gold service, and has a credit limit of $10,000. Fabrikam456 needs to have established trust relationships with the relevant companies and determine which additional tokens need to be supplied with each reservation request.

Alternatively, Fabrikam456 could act as a clearinghouse, redirect all requests from each user to any partner, and let the partner challenge the user for authentication and notify the customer of the policy. Although Fabrikam456 as a clearinghouse might earn advertising revenue, it needs to provide value as a travel service. In this second scenario, Fabrikam456 could offer a security-token service for its new business partners. For example, RentalCars456 may prefer to outsource the management of user information. In this case, RentalCars456 sees the advantage of not doing its own credit processing and may choose to take advantage of Fabrikam456's additional service by taking each authenticated request and calling the security-token service to retrieve credit approval from Fabrikam456.

Credit services might require additional security measures. WS-SecurityPolicy assertions give Fabrikam456 and RentalCars456 the ability to express additional security policies that the messages between Fabrikam456 and RentalCars456, which both adhere to the WS-Security specification, must provide. For example, RentalCars456 may require that all credit assertions be digitally signed and contain an expiration time.