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.

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:

<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 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).

WS-Security is a simple model for message security. It works fine for small numbers of messages exchanged between Web services occasionally. However, WS-Security has two drawbacks when a requester and a Web service engage in a prolonged, multiple-message exchange:

WS-SecureConversation solves these problems by doing for WSS:SOAP Message Security what SSL/TSL did for HTTP/TCP-IP. The endpoints use PKI and WS-Security to exchange a session-specific set of keys. This allows for more efficient encryption and improved security for keys.

The key concepts in WS-SecureConversation are the Security Context and the Security Context Token (SCT). WS-SecureConversation defines the format and schema for an SCT. WS-SecureConversation also defines an extended binding of WS-Trust, which allows Secure Token Servers to generate and return SCTs. In another model, a Web service requester can itself generate an SCT.

Messages within a conversation contain the SCT in a header included by the sending Web service. The SCT contains or implies a shared secret. The requesting Web service obtains the secret from an STS in a RSTR, and then forwards the secret (encrypted) to another service. WS-SecureConversation documents algorithms for using the shared secret to derive session keys to be used for encrypting communication exchanged within the conversation.

Web Services Privacy Framework (WS-Privacy) describes syntax and semantics for binding privacy policies to Web services and instances of data in messages. The main emphases of WS-Privacy are on enabling policies to be processed by Web service providers and requesters (in contrast to interfacing with human users), and on ensuring good usability in chains of Web service invocations within or across enterprises. WS-Privacy builds on WS-Policy and related standards. It does not define a new privacy policy language, but it offers the means to bind such existing languages to a Web service.

Web services often handle sensitive personal data, including a person’s attributes, typical B2C customer data such as shipping address and credit card number, and detailed customer records in B2C and B2B scenarios. Web services might act on behalf of a requester, such as an appointment calendar service, so that essentially the data remains personal.

Personal data usually falls under a privacy policy, which restricts its usage to specific purposes and recipients. This privacy policy can be partially prescribed by law, be stated voluntarily by a service owner, or be set by the person concerned. A goal of Web services is widespread interoperability, and it is thus expected that services with different purposes and different owners will frequently interact. Hence, it is essential that Web services be able to adapt their interaction patterns in accordance with promised or required privacy restrictions, and that such restrictions can be communicated between different Web services.

Furthermore, many Web services can handle data from multiple sources, which might be governed by different and varying policies. An example would be a Web service requiring access to your passport number and driver’s license number. Each piece of data can be gathered from a different source, and thus can have a different privacy policy. For such services, it is important to be flexible in adapting to these policies at different levels of granularity. This applies both to services that respond directly to the requesters and to those that offer processing facilities within an enterprise, such as storage or statistics services.

Because privacy polices are written in native policy languages, there must be a way of incorporating native privacy policies into wsp:Policy assertions. This is done with a new type of assertion, called a privacy assertion. A WS-Policy policy can incorporate this privacy assertion to indicate the privacy promises and requirements of services and data elements.

A privacy assertion is a promise that the policy’s subject makes about how the privacy-sensitive data it receives will be used in the future. It can also represent a privacy requirement that the policy’s subject expects the receiver of privacy-sensitive data to honor.

The term federated identity has various meanings. To an individual user, it means the ability to associate his various application and system identities with one another. To an enterprise, federated identity provides a standardized means for directly providing services for trusted third-party users, or those that the business doesn’t manage directly. An enterprise associates with others in a federation, such that the identities from one enterprise domain (or identity provider) are granted access to the services of the other enterprises (or service providers).

Federated Identity Management refers to the set of business agreements, technical agreements, and policies that enable companies to become partners. This lowers their overall identity management costs, improves the user experience, and mitigates security risks in Web services-based interactions.

WS-Federation builds on this specification to define mechanisms for brokering and federating trust, identity, and claims. Federation is the overall term for a set of distinct, heterogeneous enterprises that want to provide an easy-to-use, single sign-on identity model to their users. Single sign-on means that after a user signs on with one member of the federation, he can interact with other members without reauthentication. Enterprises can be corporate entities, Internet Service Providers (ISPs), or associations of individuals.

A federated environment differs from a traditional single sign-on environment in that there are no established rules limiting how enterprises transfer information about a user. However, there might be an established business policy for an enterprise’s participation in the federation, much like there is today when companies decide to do business together.

WS-Federation describes how to use the existing Web services security building blocks to provide federation functionality, including trust, single sign-on (and single sign-off), and attribute management across a federation. WS-Federation is really a family of three specifications: WS-Federation, WS-Federation Passive Client, and WS-Federation Active Client.

WS-Federation itself describes how to implement a federation in a Web services world. In particular, WS-Federation focuses on the relationships between parties, and the high-level architecture that supports these relationships. The two individual documents, WS-Federation Active and WS-Federation Passive, describe how to implement individual federation solutions.

WS-Federation Active describes how to implement federation functionality in the active client environment. Active clients are those that are Web services-enabled. That is, they can issue Web service requests and react to a Web service’s response. Leveraging the Web services security stack, WS-Fed Active describes how to implement the advantages of a federation relationship, including single sign-on, in an active client environment.

WS-Federation Passive describes how to implement federation functionality in a passive client environment. A passive client is one that is not Web services-enabled. The most common passive client is a plain old HTTP browser. WS-Fed Passive describes how to leverage the advantages of a federation relationship, such as single sign-on, in a passive client environment. Because this solution uses the WS-Security foundation of the infrastructure support, the same components used to provide a passive client solution might be utilized for an active client solution as well.

The logical architecture described in WS-Federation, together with the functionality described in the Web services security stack, supports both the active and passive client scenarios. The complete family of WS-Security specifications provides companies with a standards-based, interoperable, secure digital identity and trust platform for Web services-based architecture. Furthermore, these specifications promote reusability of existing IT security investments, enabling companies to work with multiple security token types and multiple scenarios, including HTTP browsers, enhanced browsers, active clients, and application-to-application connectivity.

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

WS-Authorization is designed 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.

WSS: SOAP Message Security defines the basic mechanisms for providing secure messaging, and for carrying security tokens that represent a set of claims. WS-Authorization uses these basic mechanisms, and defines additional primitives and extensions for security token exchange to enable the issuance and dissemination of credentials regarding authorization within different trust domains.

To protect information assets, a service provider needs to ensure that the accessing requester is qualified. WS-Authorization defines extensions to WS-Trust for issuing and exchanging authorization tokens. Using these extensions, applications can engage in secure communication designed to work with the general Web services framework, including WSDL service descriptions and SOAP messages.

To achieve this, WS-Authorization reuses headers and elements defined by the WS-Trust specification to request authorization tokens and manage authorization policies. An authorization token is a kind of security token, and therefore it is possible to reuse the existing Web service infrastructure that deals with security tokens.

In the Web service security model defined in WS-Authorization, a Web service checks whether an incoming access request with a set of claims (such as name, privilege, capability, and so on) and contextual information (such as current time and so on) is qualified to invoke the target service or to perform the requested operation. If the requester is not qualified, the Web service ignores or rejects the request. A service can indicate its required claims and related information in its policy, as described by WS-Policy and WS-PolicyAttachment specifications. How to request claims in relevance to security tokens from a security token service is described in the WS-Trust specification.

An authorization check is performed by an authorization service, a kind of STS (security token service) defined in WS-Trust. A requester or a Web service can invoke the authorization service with an appropriate set of claims and security tokens. The authorization service retrieves the applicable authorization policies and determines whether the access should be allowed or denied, using an authorization engine. It returns the result of the authorization, either by issuing an authorization token or by returning some messages. The authorization token proves the privileges or capabilities of the holder of the token, but it could cover broader semantics, such as a validation result (valid or invalid) of the authorization token, enumerated rights of the requester, and conditional responses (the access is allowed, provided such-and-such a condition is satisfied). The authorization token is one of the security tokens defined in WSS: SOAP Message Security and relevant specifications. Thus, the mechanism designed for issuing and exchanging security tokens in WS-Trust is reusable in WS-Authorization specification. The model that is adapted from WS-Trust is illustrated in Figure 13-2.

Figure 13-2. The trust model of WS-Trust.

The authorization service returns an error message if the authorization service cannot process the access request correctly. For example, some claims or the security tokens are missing and there is no applicable rule found for the requested service.

The authorization service does not assume any specific authorization engines, authorization policy specification languages, or authorization tokens. The authorization model defines interfaces between an authorization service and a requester, or an authorization service and a Web service.

The security of the Web service authorization model depends on the authorization policy managed by the authorization service.

WS-SecurityPolicy defines policy assertions for the security properties of Web services. In particular, WS-SecurityPolicy defines policy assertions for use with WS-Policy that apply to WSS: SOAP Message Security, WS-Trust, and WS-SecureConversation. These assertions are primarily designed for describing policies related to the features defined in the WSS: SOAP Message Security, WS-Trust, and WS-SecureConversation specifications, but they can also be used for describing security requirements at a more abstract or transport-independent level.

The primary goal of WS-SecurityPolicy is to define an initial set of assertions that describe how messages are secured on a communication path. The intent is to allow flexibility in terms of the tokens, cryptography, and mechanisms used, including leveraging transport security, while being specific enough to ensure interoperability based on assertion matching.

One goal of the security policy model is to leverage the WS-Policy framework. Consequently, wherever possible, the security policy assertions do not use parameters or attributes. This enables element QName matching without security domain-specific knowledge (see Chapter 7, “Web Services Policy”).

To provide richer semantics for combinations of security constraints and requirements, and to enable element QName matching of policy assertions, the assertions are separated into simple types: those that express what parts of a message are being secured (scope), those expressing general aspects or preconditions of the security model (conditions), and those identifying the mechanism that is used to provide the security (security binding).

To indicate the scope of the constraints and requirements, assertions identify body parts that are to be protected in a specific way, such as integrity or confidentiality protection.

The general aspects of security include the characteristics of the environment in which security is being applied, such as the tokens being used, which ones are for authentication and which are supporting, the applicable algorithms to use, and so on.

The security mechanism, or binding, defines how the general aspects are used to protect the indicated parts. For example, it could specify that an asymmetric token is used with a digital signature to provide authentication and integrity, and that parts are encrypted with a symmetric key, which is then encrypted using the public key of the recipient. In its simplest form, the binding defines a strong type for the open-ended and extensible <wsse:Security> header.

Because these characteristics are separated into assertions, many of them can be simplified so that assertion matching is sufficient, and many aspects of security can be factored out and reused. For example, it might be common that the mechanism is constant for an endpoint, but that the parts protected vary by message action.

As previously indicated, the binding defines the mechanism for providing the security. These assertions are used to determine how the security is performed and what to expect in the <wsse:Security> header.

Bindings are described textually and enforced programmatically. This specification defines several bindings, but others can be defined and agreed to if participating parties support it.

A binding defines the following:

These elements, along with the assertions describing conditions and scope, provide enough information to secure messages between an initiator and a receiver.

The specifications discussed in this chapter provide a strong foundation to secure Web services interactions, supporting sophisticated, automated business-to-business interactions. Additional technologies, not explicitly covered in the specifications discussed here, provide support for specific circumstances that often arise in the course of a business transaction. This section discusses the use of public key cryptography and how to provide non-repudiation capabilities in Web services interactions.

Sometimes the parties in a business transaction will have a dispute. To protect the interests of these parties, some evidence of the agreement must be generated and preserved, in the event that a third party must be called in to resolve the dispute. In the case of transactions initiated via Web service messages, this evidence must consist of Proof of Message Origin, Proof of Message Receipt, and Original Message content.

Secret-key cryptography alone is not sufficient to prevent the denial of an action that has taken place, such as the initiation of an electronic transaction. One can apply data privacy in such a scenario, but the fundamental flaw of a non-repudiation scheme based on secret-key cryptography is that the secret key is dispensed to more than one party.

Data Integrity and Data-Origin Authentication

At a much lesser cost than encrypting the entirety of a plain text, data integrity and data-origin authentication can be ensured by a secret cryptographic scheme using a Message Authentication Code (MAC) function.

The basic idea is to attach to each message, m, that is sent across a network the result, h(m), of a mathematical function, h, applied to m itself. If an error has occurred during the message’s transmission, and the received message, a, is different than m, the message’s receiver can detect the anomaly by independently computing h(a) and comparing it with h(m).

Figure 13-3. Using MACs to detect anomalies.

The main component of a MAC function is a hash digest function, which is considered to be one of the fundamental primitives in modern cryptography. By definition, a hash digest function is a deterministic function that maps a message of arbitrary length to a string of fixed length, n. Typically, n is 128 or 160 bits. The result is commonly known as a message digest. Because the original data is often longer than its hash value, this is also referred to as the original message’s fingerprint.

Figure 13-4. Computing message hashes.

Of course, a hash digest function is inherently non-injective. In fact, the universe of the messages that can be digested is potentially unlimited, whereas the universe of all the message digests is limited by the set of the 2ⁿ strings with n bits. Therefore, multiple messages can map to the same digest. However, the fundamental premise is that, depending on the strength of the hashing algorithm, the hash value becomes a more compact representation of the original data. This means that it should be computationally infeasible to produce two messages having the same message digest, or to produce any message having a specified target message digest.

Message Digest V5 (MD5) and Secure Hash Algorithm V1 (SHA-1) are the most widely used cryptographic hash functions. MD5 yields a 128-bit (16-byte) hash value, while SHA-1 results in a 160-bit (20-byte) digest. SHA-1 appears to be a cryptographically stronger function. On the other hand, MD5 edges SHA-1 in computational performance and thus has become the de facto standard.

Hash functions alone cannot guarantee data integrity because they can’t guarantee data-origin authentication, or the ability to authenticate the originator of a message. The problem with digest functions is that they are publicly available. If a message, m, is intercepted by an adversary after being transmitted by Alice, the adversary can change m into a different message, m′, compute h(m′), and send Bob the pair, (m′..h(m′)). By simply applying the function h to the received message, m′, Bob has no means to detect that an adversary has replaced m with m′.

Data-origin authentication is inherently supported by secret-key cryptography, provided that the key is shared by two entities only. When three or more parties share the same key, however, origin authenticity can no longer be provided by secret-key cryptography alone. Various secret-key authentication protocols have been developed to address this limitation.

In contrast to using a simple hash function to digest a message, a MAC function combines a hash digest function with secret-key encryption. This yields a value that can be verified only by an entity that has the secret key. This enables both data integrity and data origin authentication.

Another simple way to achieve data integrity and data origin authentication is to apply a regular hash function, h, such as SHA-1 or MD5. But rather than hashing the message, m, alone, the message is first concatenated with the key, k, and then the result of the concatenation is hashed. In other words, the sender attaches to the message m the tag h(k, m). This solution has some theoretical weaknesses, however. A more reliable solution consists of attaching the tag h(k, h(k, m)).

A MAC can even be computed by using a secret-key block-cipher algorithm. For example, the last cipher text block, encrypted in CBC mode, yields the final MAC value. Therefore, the MAC so defined is a compact representation of the entire message that can be computed only by an entity that has the secret key. Known instances of this procedure employ DES and Triple-DES, resulting in DES-MAC and Triple-DES-MAC, respectively.

A MAC mechanism that uses a cryptographic hash function is also referred to as HMAC. HMAC is specified in [HMAC].

WS-Security currently does not provide a mechanism for non-repudiation. The following is one way to profile extending Web Services Security to provide Proof of Message Origin (PMO) and Proof of Message Receipt (PMR).

Web services security defines basic mechanisms to secure the interaction between a service requester and a service provider. To address the richness and the complexity of Web service interactions and their need for security, a set of additional specifications that builds on WS-Security has been published or is in the process of being published.

WS-Trust defines a basic building block for creating a trusted relationship by defining a mechanism for issuing security tokens. WS-Secure Conversation uses the mechanisms defined by WS-Trust to efficiently support secure, long-lived interactions between services. WS-Federation extends WS-Trust to allow enterprises to collaborate to provide a single sign-on identification model to customers by sharing their identity information. WS-Security Policy defines assertions to represent security requirements and capabilities in the form of a WS-Policy policy. WS-Privacy and WS-Authorization are still in the process of being completed. WS-Privacy will define how to represent privacy requirements and Web service capabilities; WS-Authorization will describe how to express and manage access policies to Web services resources.

This chapter concluded with a brief review of advanced technologies and capabilities: public key cryptography and non-repudiation.