Trust, Access Control, and Rights for Web Services Part 1

Several other important standards are derived from and are complementary to WS-Security; they relate to such fundamental security topics as trust, access control, and rights. In this chapter, we review the family of WS-Security–related technologies. This is part 1 of chapter 9 from Securing Web Services with WS-Security, by Rosenberg and Remy (ISBN 0672326515, Sams, 2004).

Securing Web Services with WS-SecuritySecurity Assertion Markup Language (SAML) was the topic of Chapter 6, “Portable Identity, Authentication, and Authorization.” WS-Security was presented in Chapter 7, “Building Security into SOAP.” Then WS-Policy was the focus of Chapter 8, “Communicating Security Policy.” They are the three pillars of WS-Security.

Several other important standards are derived from and complementary to WS-Security; they relate to such fundamental security topics as trust, access control, and rights. In this chapter, we review the family of WS-Security–related technologies. An important additional topic is the XML Key Management Specification (XKMS) for managing keys used in signatures, encryption, and SAML. We also cover two other WS-Security security related specifications not already covered: eXtensible Access Control Markup Language (XACML) and eXtensible Rights Markup Language (XrML). Let’s begin with the WS-Security family.

The WS-* Family of Security Specifications

In April 2002, IBM and Microsoft published a joint whitepaper called “Security in a Web Services World: A Proposed Architecture and Roadmap.”1 This whitepaper describes a far-reaching, comprehensive vision of a set of security standards and technologies meant to create a unifying approach for dealing with security in a Web services world. The proposed architecture attempts to bring together for Web services what, to date, had been disparate worlds in security. Just as WS-Security allows security mechanisms such as Public Key Infrastructure (PKI) and Security Assertion Markup Language (SAML) to participate in Web Services Security, the Web Services Architecture Roadmap generalizes many of the security functions that previously existed in other domains and proposes a framework for meeting the security requirements of the Web services domain. It provides an evolutionary strategy for putting the different pieces of the security puzzle in place. The proponents of this framework, and the standards bodies they are working through, are accomplishing this by first rolling out foundational specifications such as WS-Security (which, in turn, was built on XML Signature, XML Encryption, SAML, and various other security token standards) and then following with other standards that rely on these foundational standards. Figure 9.1 repeats the diagram shown previously in Chapter 7; in this figure, you can see the related WS-Security standards as well as the dependencies.

Trust, Access Control, and Rights for Web Services

Figure 9.1  The WS-Security family of standards built on SOAP.

As a quick review, WS-Security describes SOAP extensions for securing messages. It is a general-purpose mechanism for associating security tokens with SOAP messages. WS-Security builds on and is fully compatible with established, mature security technologies such as SSL, IPsec, XML Signature, and XML Encryption. It is designed to address message integrity, message confidentiality, message authentication, and the encoding of security tokens that must travel with the messages they are securing.

WS-Security provides the foundations for the set of composable security building blocks in Figure 9.1 built on top of WS-Security. By composable, we mean that various building block standards can be combined to provide new and different security standards to solve specific security challenges. For example, WS-Privacy is composed from WS-Security plus WS-Trust and WS-Policy. These composable standards provide a “use only what you need” approach to securing Web services. The composable specifications still under development together with WS-Security are built on a core foundation of technologies such as SOAP, WSDL, XML Signature, XML Encryption, and SSL.

SamsThis chapter is from Securing Web Services Security with WS-Security, by Jothy Rosenberg and David Remy (Sams, 2004, ISBN: 0672326515). Check it out at your favorite bookstore today.

Buy this book now.

{mospagebreak title=Building Blocks}

What is amazing is that, with this model, for the first time users have an approach that allows integration of Kerberos, X.509/PKI, and other security models. Building up from WS-Security are the following composable building blocks:

  • WS-Policy—Defines how to express capabilities and constraints of security policy. (This topic was covered in Chapter 8 but is summarized here.)

  • WS-Trust—Describes the model for establishing both direct and brokered trust relationships, including intermediaries.

  • WS-Privacy—Enables users to state privacy preferences and Web services to state and implement privacy practices.

  • WS-SecureConversation—Describes how to manage and authenticate message exchanges between parties, including exchanging security contexts and establishing and deriving session keys.

  • WS-Federation—Describes how to manage and broker the trust relationships in a heterogeneous federated environment, including support for federated identities.

  • WS-Authorization—Defines how Web services manage authorization data and policies.


Note - The purpose of describing all these “standards” here, even when some of them are as yet unpublished, is two-fold. First, we hope our introduction to these evolving specifications will help you avoid re-inventing the wheel on an area you need for your Web services to be successful. Second, our goal is to let you know that significant work is being done on these standards, and progress is rapid. Consequently, if these standards are important to you, you will be able to find some useful guidance by scouring the Web and the standards bodies’ repositories.


WS-Security and the layers above it support what could be called the triangle of distributed message-based security that is composed of trust, interoperability, and integration. The triangle of WS-Security specifications is shown in Figure 9.2.

Trust, Access Control, and Rights for Web Services

Figure 9.2  The WS-* Security triangle of trust,
integration, and interoperability.

The first point of the security triangle is trust. Trust, of course, is fundamental to security. No trust, no security. In a Web services world, trust is very complex. Trust is represented in relationships; it can be explicitly established, or it may be presumed. Assertions are used to represent trust and trust relationships. WS-Trust is the WS-* security standard building block focused on trust relationships. The other trust-related standard in this point of the security triangle is WS-Privacy. WS-Privacy specifies the rules that must be followed when an entity trusts a service with its self-descriptive (that is, personally identifiable) data.

The second point of the security triangle is interoperability. You can think of interoperability in terms of communication standards that allow distinct systems to cooperate. This capability is especially important when those communications are secured. Secure communications adhere to several different protocols, so interoperable secure communications must be able to map one protocol to another. Besides WS-Security itself, the two other WS-* security family standards that relate to interoperability are WS-Policy and WS-SecureConversation.

The third point of the security triangle is integration. Web services’ primary raison d’etre is for application and organizational integration. Integration involves one system that previously did not communicate with another extending its architecture to be able to do so. It means that existing services are reused for new purposes. This necessarily means that identities and the trust model under which they operate need to interoperate and do so across heterogeneous environments. An important issue this raises is federation. Federation is the agreement among a group of entities that they will share identities as well as the attributes of those identities with other members of their group. Two of the WS-* family of standards relate to integration: WS-Federation and WS-Authorization.

SamsThis chapter is from Securing Web Services Security with WS-Security, by Jothy Rosenberg and David Remy (Sams, 2004, ISBN: 0672326515). Check it out at your favorite bookstore today.

Buy this book now.

{mospagebreak title=WS-* Security Specifications for Trust Relationships}

The following sections address the two specifications for trust relationships. First, we cover WS-Trust and then WS-Privacy.

WS-Trust

Throughout this book, we have described the technical issues around securing Web services. Although these issues can be complex, they are still only technical issues. By far, the most difficult issues arise around the more subtle business and personal issues of trust. Think about your own definition of trust and how you determine whom to trust. Do you trust someone who has been referred by someone else you trust? Do you trust in some people in relatively low-risk situations but not in a high-risk situation? How you determine trust might be called your personal trust model. A lot of work and thought has gone into defining, describing, and implementing trust models, and much of the complexity in Public Key Infrastructure technology derives from the complexity of modeling trust.

A major Web services trust problem arises when credentials are issued in one trust domain and then presented in another. Say your employer, ABC Supply, is a supplier to XYZ Truck Company, and XYZ Truck Company has decided to expose its critical business systems to its suppliers. One strategy could be for XYZ Truck Company to directly issue credentials to each individual within every supplier and take on the management of these credentials. This would mean that, even if you do not work for XYZ, you would receive a credential from the company to present to its Web service when using its Bid for Order Web service. But how would XYZ Truck Company know if you were to be fired from ABC Supply or change positions? It would be very difficult, if not impossible, for XYZ Truck Company to manage the credentials given to those privileged few employees of ABC Supply allowed to directly order at XYZ.

Another approach that XYZ could choose is to blindly trust ABC Supply (and all its employees). From a technical perspective, this strategy might mean that X.509 certificates issued by ABC Supply (probably with certain attributes) could be presented to XYZ Truck Company for access to its Web services. You can probably see the trust issues here immediately. Perhaps these are highly sensitive capabilities that XYZ Truck Company is allowing access to, so much so that even its own employees must show up in person to be granted a credential. Suppose XYZ Truck Company has tight procedures for periodically refreshing credentials and revoking them when they are lost or the employee changes responsibilities. If ABC Supply Company does not have similar rigorous procedures, XYZ Company has seriously degraded its security by opening up the company to ABC’s much lower standards. This level of trust becomes the arena of contracts and law because that is the way that companies express their trust, or lack thereof, and the way violations of that trust become enforceable.

SamsThis chapter is from Securing Web Services Security with WS-Security, by Jothy Rosenberg and David Remy (Sams, 2004, ISBN: 0672326515). Check it out at your favorite bookstore today.

Buy this book now.

{mospagebreak title=Prior to Having Secure Communications…}

Prior to having secure communications, each party needs to determine whether it can “trust” the asserted credentials of the other party. WS-Trust defines extensions to WS-Security that provide

  • Methods for issuing and exchanging security tokens

  • Ways to establish and access the presence of trust relationships

Similar to SAML, WS-Trust defines a request/response mechanism for obtaining security tokens.

The most important attributes of WS-Trust to understand are

  • The relationships between Web service requestor, Web service provider, and the Security Token Service (STS), as shown in Figure 9.3

  • These two methods: <RequestSecurityToken> and <RequestSecurityTokenResponse>

Security Token Services form the basis of trust by issuing security tokens that can be used to broker trust relationships between different trust domains. As Figure 9.3 shows, a Security Token Service is a trust broker ready and willing to provide a Web service with a way to determine whether it will trust an incoming request from a different (possibly unknown) trust domain. A policy statement at the Web service provider notifies the Web service requestor that a security token is required for use of this service. The requestor provides such a token, either having obtained it previously or by the requestor now sending a <RequestSecurityToken> to the Security Token Service. The so-obtained WS-Security–compatible security token is then provided when requesting service from the Web service provider. WS-Trust also provides for a challenge-response protocol for the Web service provider to strongly validate the efficacy and timeliness of the requestor’s security token.

Trust, Access Control, and Rights for Web Services

Figure 9.3 The WS-Trust model for providing a Security
Token Service trust broker in support of WS-Security.

The Web service security model defined in WS-Trust is based on a process in which a Web service can require that an incoming message prove a set of claims (for example, name, key, permission, capability, and so forth). If a message arrives without having the required proof of claims, the service ignores or rejects the message outright. A service can indicate its required claims and related information in its policy as described by the WS-Policy and WS-PolicyAttachment specifications described in detail in Chapter 8.

A requestor can send messages that demonstrate its ability to prove a required set of claims by associating security tokens with the messages and including message signatures that demonstrate proof of possession of (the contents of) the tokens.

If the requestor does not have the necessary token or tokens to prove the claim, it contacts a Security Token Service and obtains the tokens. These “authorities” may, in turn, require their own set of claims.

The WS-Trust model illustrated in Figure 9.3 shows that any requestor may also be a service and that the Security Token Service is itself a Web service, including expressing policy and requiring security tokens.

This general messaging model—claims, policies, and security tokens—subsumes and supports several more specific models, such as identity-based security, access control lists, and capabilities-based security. It allows use of existing technologies such as X.509 public key certificates, XML-based tokens, Kerberos shared-secret tickets, and even passwords. The general model, in combination with the WS-Security and WS-Policy primitives, is sufficient to construct higher-level key exchange, authentication, policy-based access decisions, auditing, and complex trust relationships.

A quick overview of the WS-Trust model is that a Web service has a policy applied to it, receives a message from a requestor that possibly includes security tokens, and may have some protection applied to it using WS-Security mechanisms. The following steps are performed by the trust engine of a Web service:

  1. Verify that the claims in the requestor’s security token are sufficient to comply with the provider’s policy and that the message conforms to this policy.

  2. Verify that the attributes of the claimant are proven by the signatures. In brokered trust models, the signature may not verify the identity of the claimant; it may verify the identity of the intermediary, who may simply assert the identity of the claimant. The claims are either proven or not based on policy.

  3. Verify 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 to exchange them for other security tokens that it can use directly in its evaluation.

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

SamsThis chapter is from Securing Web Services Security with WS-Security, by Jothy Rosenberg and David Remy (Sams, 2004, ISBN: 0672326515). Check it out at your favorite bookstore today.

Buy this book now.

{mospagebreak title=RequestSecurityToken}

Now that you know how the model is supposed to work and you understand the key relationships between Web service provider, requestor, and Security Token Service, it’s time to look at the two key WS-Trust elements needed to perform its prescribed functions: <RequestSecurityToken> and <RequestSecurityTokenResponse>.

<RequestSecurityToken>

Listing 9.1 shows a request to have a security token issued.

Listing 9.1 The <RequestSecurityToken> Element

<RequestSecurityToken>
  <TokenType>…</TokenType>
  <RequestType>…</RequestType>
  <Base>…</Base>
  <Supporting>…</Supporting>
</RequestSecurityToken>

Now let’s explore each element that makes up a <RequestSecurityToken> element.

<TokenType> The optional <TokenType> element describes the type of security token requested, specified as a QName (see the following section). That is, it describes the type of token that will be returned in the <RequestSecurityTokenResponse> message.

<RequestType> The <RequestType> element is used to indicate, using a QName, the action that is being requested. The following QNames are predefined:

QName

Description

wsse:ReqIssue

Issue security token

wsse:ReqValidate

Validate security token

wsse:ReqExchange

Exchange security token


<Base> The optional <Base> element has the same type as the <SecurityTokenReference> element and references the base (primary) tokens that are used to validate the authenticity of a request. In general, this element isn’t used because signatures provided on the request prove the right to make the request.

<Supporting> The optional <Supporting> element has the same type as the <SecurityTokenReference> element and references the supporting tokens that are used to authorize this request. Typically, this element is used to identify tokens in a certificate authority. It is not required to specify any or all supporting tokens; it is simply a hint or aid to the recipient service.

The example in Listing 9.2 shows an X.509 security token being requested based on the security token located in the <Security> header with the ID “myToken”. This token specifies a username, and a signature is placed over the request using a key derived from the password (or password equivalent), nonce, and time stamp.

Listing 9.2 – Requesting an X.509 Security Token Based on a Key Derived from a Password

<S:Envelope xmlns:S=”…” xmlns=”…/secext” xmlns:wsu=”…/utility>
  <S:Header>
    …
    <Security>
      <UsernameToken wsu:Id=”myToken”>
        <Username>NNK</Username>
        <Nonce>FKJh…</Nonce>
        <wsu:Created>2001-10-13T09:00:00Z </wsu:Created>
      </UsernameToken>
      <ds:Signature xmlns:ds=”…”>
        …
      </ds:Signature>
    </Security>
    …
  </S:Header>
  <S:Body wsu:Id=”req”>
    <RequestSecurityToken>
      <TokenType>wsse:X509v3</TokenType>
      <RequestType>wsse:ReqIssue</RequestType>
      <Base>
        <Reference URI=”#myToken”/>
      </Base>
    </RequestSecurityToken>
  </S:Body>
</S:Envelope>

SamsThis chapter is from Securing Web Services Security with WS-Security, by Jothy Rosenberg and David Remy (Sams, 2004, ISBN: 0672326515). Check it out at your favorite bookstore today.

Buy this book now.

{mospagebreak title=RequestSecurity TokenResponse}

<RequestSecurityTokenResponse>

The other half of <RequestSecurityToken> is <RequestSecurityTokenResponse>. The syntax for this element is shown in Listing 9.3.

Listing 9.3 The <RequestSecurityTokenResponse> Element

<RequestSecurityTokenResponse>
 <TokenType>…</TokenType>
 <KeyType>…</KeyType>
 <KeySize>…</KeySize>
 <wsp:AppliesTo>…</wsp:AppliesTo>
  <RequestedSecurityToken>…</RequestedSecurityToken>
 <RequestedProofToken>…</RequestedProofToken>
</RequestSecurityTokenResponse>

Let’s look at each element in <RequestSecurityTokenResponse> in turn.

<TokenType> The optional <TokenType> element specifies the type of security token returned. Either this element or the optional <AppliesTo> element should be specified. <TokenType> must be provided if a token type other than the requested type is returned.

<KeyType> The optional <KeyType> element specifies the type of key used in the token.

<KeySize> The optional <KeySize> element specifies the size of the key returned.

<wsp:AppliesTo> The optional <wsp:AppliesTo> element specifies the scope to which this security token applies. The WS-PolicyAttachment specification deals with this scope in detail.

<RequestedSecurityToken> The optional <RequestedSecurityToken> element is used to return the requested security token. Normally, this element contains the requested security token, but a security token reference may be used instead. For example, if the requested security token is used in securing the message, the security token is placed into the <Security> header, and a <SecurityTokenReference> element is placed inside the <RequestedSecurityToken> element to reference the token in the <Security> header. Although this element is optional, at least one of <RequestedSecurityToken> or <RequestedProofToken> will be returned unless an error occurs.

<RequestedProofToken> The optional <RequestedProofToken> element is used to return the proof-of-possession token associated with the requested security token. Proof of possession is needed when the client does not provide the public key to use and signs (authenticates) this using the corresponding private key, thereby proving possession. Normally, this element contains the proof-of-possession token, but a security token reference may be used instead. The token (or reference) is specified as the content of this element. For example, if the proof token is used in securing the message, it is placed in the <Security> header, and a <SecurityTokenReference> element is used inside the <RequestedProofToken> element to reference the token in the <Security> header.

Listing 9.4 is a sample response to a request for a security token. In this example, a pre-existing X.509v3 digital certificate, looked up in a directory and encoded into a security token, is returned. As is typical, this example does not return an explicit proof of possession because the client implicitly provided proof of possession by providing the public key to use (and authenticated it using the corresponding private key).

Listing 9.4 <RequestSecurityTokenResponse> Returning a Pre-existing X.509v3 Certificate

<RequestSecurityTokenResponse>
  <RequestedSecurityToken>
    <BinarySecurityToken ValueType=”wsse:X509v3″
               EncodingType=”wsse:Base64Binary”>
       MIIEZzCCA9CgAwIBAgIQEmtJZc0…
    </BinarySecurityToken>
  </RequestedSecurityToken>
</RequestSecurityTokenResponse>

WS-Privacy

WS-Privacy is a not-yet-published proposed standard that will use a combination of WS-Policy, WS-Security, and WS-Trust to communicate privacy policies. It is designed to be used by organizations that deploy Web services and require that incoming SOAP requests contain claims that the sender conforms to the service provider’s privacy policies. WS-Security encapsulates these claims into security tokens that are verified before accepting any incoming SOAP request.

WS-Privacy will be a standard that allows Web service providers and requestors to state their privacy preferences and organizational privacy practice statements. As of this writing, no public draft of WS-Privacy is available, but from the information that has been published, it will likely be similar to the W3C’s Platform for Project Privacy Preferences (P3P).2 P3P was primarily designed for the Web application world (versus the Web services world). It allows an organization to specify its privacy policy in a structured manner and post it on the Web server that is being accessed. Then a P3P-enabled browser can read this policy and compare it to the browser user’s privacy preferences. Thus, a user can express her privacy preferences and be notified when she surfs to a site that has privacy practices that conflict with her stated preferences. In a similar manner, WS-Privacy will allow this type of privacy policy exchange and agreement for Web services.

As an example, an individual would state a set of “privacy preferences” that describe what the individual does or does not want to allow applications acting on his behalf to do with his personal information. A calendaring application, working on the individual’s behalf, can now access a calendaring service that uses a set of “privacy practice rules” to make statements and decisions about use and disclosure of personal information. The calendar service makes the decision by combining the privacy practice rules with the privacy preferences to determine whether a proposed use or disclosure is permissible.

SamsThis chapter is from Securing Web Services Security with WS-Security, by Jothy Rosenberg and David Remy (Sams, 2004, ISBN: 0672326515). Check it out at your favorite bookstore today.

Buy this book now.

{mospagebreak title=WS-* Security Specifications for Interoperability}

The following sections address the two WS-* security specifications for interoperability. First, we briefly review WS-Policy and then cover WS-SecureConversation.

WS-Policy

WS-Policy was the subject of Chapter 8; we include a brief review of it here for its context within the WS-* family of specifications.

WS-Policy is a family of three specifications. Version 1.1 of the WS-Policy documents include Web Services Policy Framework (WS-Policy), Web Services Policy Assertions Language (WS-PolicyAssertions), and Web Services Policy Attachment (WS-PolicyAttachment).

The top level of these specifications is WS-Policy. It forms the framework by providing a general-purpose model 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.

WS-PolicyAssertions specifies a set of common message policy assertions that can be specified within a policy.

WS-PolicyAttachment specifies three specific attachment mechanisms for using policy expressions with existing XML Web service technologies. Specifically, it defines how to associate policy expressions with WSDL-type definitions and UDDI entities. It also defines how to associate implementation-specific policy with all or part of a WSDL portType when exposed from a specific implementation.

Overall, the WS-Policy family describes a language for expressing requirements of Web services senders, receivers, and endpoints. One type of policy requirement that will be placed on senders, receivers, and endpoints is the security of the extended conversation implemented in a Web service. Sounds like a requirement for a “secure conversation,” doesn’t it? As you will see, WS-SecureConversation does indeed sit on top of WS-Policy, reinforcing the statement that WS-Policy is a framework for richer Web Services Security constructs.

WS-SecureConversation

WS-SecureConversation, developed by IBM, Microsoft, RSA, and VeriSign, is in initial public draft form last published in December 2002. What SSL does at the transport layer in point-to-point communication, WS-SecureConversation does at the SOAP layer. It makes efficient what would otherwise be individual SOAP messages carrying authentication information in tokens that would have to be evaluated and checked against security policy. In contrast, WS-SecureConversation establishes a mutually authenticated security context in which a series of messages are exchanged. Despite being at the top of the stack and therefore initially considered one of the later specifications to be published, a draft of WS-SecureConversation3 was published fairly early on.

WS-Security secures SOAP and thereby has a message-level security focus. But many Web service conversations span multiple messages and need an efficient way to secure those conversations. Furthermore, WS-Security is subject to certain kinds of attacks that can be thoroughly addressed only by authenticating a series of messages, not just one message at a time. WS-Security focuses on a single message authentication model in which the message itself must contain everything necessary to authenticate itself. This model can be inefficient considering that, if the exact same message comes in again and again, each time it would go through the same authentication/verification process, which is computationally expensive. WS-Security is well suited for coarse-grained messaging in which a single message at a time (or few in number) from the same requestor are received. When multiple messages are to be exchanged, establishing a security context can greatly improve efficiency. This security context, which contains a shared secret used by both parties to encrypt and/or sign, is shared among the communicating parties until the session expires.

Like SSL, WS-SecureConversation uses public key (asymmetric) encryption to establish a shared secret key and from then on uses shared key (symmetric) encryption for efficiency. The same shared key is used to encrypt a series of SOAP messages.

SamsThis chapter is from Securing Web Services Security with WS-Security, by Jothy Rosenberg and David Remy (Sams, 2004, ISBN: 0672326515). Check it out at your favorite bookstore today.

Buy this book now.

{mospagebreak title=SecurityContextToken}

<SecurityContextToken>

The structure of a WS-SecureConversation is based on the <SecurityContextToken> element. This element is a security token that describes a security context. This is the context that will apply to one or more messages to follow. The structure of <SecurityContextToken> is shown in Listing 9.5.

Listing 9.5 The <SecurityContextToken> Element

<wsse:SecurityContextToken wsu:Id=”…”>
  <wsu:Identifier>…</wsu:Identifier>
  <wsu:Created>…</wsu:Created>
  <wsu:Expires>…</wsu:Expires>
  <wsse:Keys>
    <xenc:EncryptedKey Id=”  “>…</xenc:EncryptedKey>
   <wsse:SecurityTokenReference>…</wsse:SecurityTokenReference>
    …
  </wsse:Keys>
</wsse:SecurityContextToken>

The elements and attributes used in a <wsse:SecurityContextToken> element are described in the following sections.

<wsu:Identifier> The required <wsu:Identifier> element identifies the security context using a URI. This security context URI must be globally unique to both the sender and recipient.

<wsu:Created> The optional <wsu:Created> element indicates the creation time of the security context. It is typically specified only on the first use of the token.

<wsu:Expires> The optional <wsu:Expires> element indicates the expiration time of the security context according to the requestor’s clock. It is typically specified only on the first use of the token.

<Keys> The optional <Keys> element holds the shared secrets of the security context. It is typically specified only on the first use of the token. If no <Keys> element is specified, the shared secret is assumed to be already known and associated with the security context identified by the URI specified in the <Identifier> element.

<xenc:EncryptedKey> The optional <xenc:EncryptedKey> element holds the shared secret of the security context.

<xenc:EncryptedKey/@Id> The optional <xenc:EncryptedKey/@Id> attribute specifies an “ID” for the key. Note that this does not use the wsu:Id attribute because the schema doesn’t allow for attribute extensibility.

<SecurityTokenReference> The optional <SecurityTokenReference> element references the shared secret of the security context.

Establishing a Security Context

There are three ways to establish a security context:

  • The security context token can be created by an independent third-party token service.

  • The security context token can be created by one of the communicating parties and propagated with a message.

  • The security context token can be created through negotiation.

Security Context Token Created by a Security Token Service The initiator can ask a Security Token Service to create a new security context token. The newly created security context token is distributed to the parties through the protocols defined by WS-SecureConversation and WS-Trust. For this scenario, the initiating party sends a <RequestSecurityToken> request to the token service, and a <RequestSecurityTokenResponse> is returned. The response contains a <SecurityTokenReference> pointing to the new security context token and a <ProofTokenReference> pointing to the “secret” for the returned context.

Security Context Token Created by One of the Communicating Parties and Propagated with a Message The initiator can create a security context token and send it to the other parties on a message using the mechanisms described here and in WS-Security. This model works when the sender is trusted to always create a new security context token. For this scenario, the initiating party creates a security context token and issues a signed unsolicited <RequestSecurityTokenResponse> to the other party. The message contains a <SecurityTokenReference> pointing to the new security context token and a <ProofTokenReference> pointing to the “secret” for the security context token. The recipient can then choose whether to accept the security context token.

Security Context Token Created Through Negotiation When participants need to negotiate about the contents of the security context token, such as a shared secret, WS-SecureConversation allows the parties to exchange data to establish the security context. For this scenario, the initiating party sends a <RequestSecurityToken> request to the other party, and a <RequestSecurityTokenResponse> is returned. It is likely that the negotiation (challenge/response) semantics described in WS-Trust will be used. Ultimately (if successful), a final response contains a <SecurityTokenReference> pointing to the new security context and a <ProofTokenReference> pointing to the “secret” for the context.

After the shared secret security context token is established for both parties, it is used within WS-Security to secure each message sent as part of a WS-SecureConversation. This scenario is shown in Listing 9.6.

Listing 9.6 Use of a Shared Secret Security Context in WS-Security as Part of WS-SecureConversation

<?xml version=”1.0″ encoding=”utf-8″?>
<S:Envelope xmlns:S=”…” xmlns:ds=”…” xmlns:wsse=”…”>
 <S:Header>
  …
  <wsse:Security>
   <wsse:SecurityContextToken wsu:Id=”MyID”
    <wsu:Identifier>uuid:…</wsu:Identifier>
   </wsse:SecurityContextToken>
   <ds:Signature>
   …
    <ds:KeyInfo>
     <wsse:SecurityTokenReference>
      <wsse:Reference URI=”#MyID”/>
     </wsse:SecurityTokenReference>
    </ds:KeyInfo>
   </ds:Signature>
  </wsse:Security>
 </S:Header>
 <S:Body wsu:Id=”MsgBody”>
  <tru:StockSymbol xmlns:tru=”
http://fabrikam123.com/payloads“>
    QQQ
  </tru:StockSymbol>
 </S:Body>
</S:Envelope>

Listing 9.6 is a standard SOAP message, so it begins with a SOAP message header followed by the SOAP body. The SOAP header contains the WS-Security <Security> header block, which contains the security-related information for the message. Inside the WS-Security block is a security token associated with the message inside a <SecurityContextToken> element. A URI within this element specifies the unique ID of the context. The digital signature uses the security context just established—in this case, based on the secret key associated with the context. The contents of the XML Digital signature here are represented with ellipses (…) but would reference the body of the message. The <ds:KeyInfo> element holds the key used for the signature. Not surprisingly, it will be the security context token included in the message and therefore will just refer to the URI that is the unique ID of the context specified earlier.

The body of the message comes next and is shown here with another ellipsis.

Much, if not all, of what is described here will be handled for you by the application server platforms and the development tools that support them. It is important to know what they are doing and why, but the details are hidden behind your development tools.

SamsThis chapter is from Securing Web Services Security with WS-Security, by Jothy Rosenberg and David Remy (Sams, 2004, ISBN: 0672326515). Check it out at your favorite bookstore today.

Buy this book now.

{mospagebreak title=WS-* Security Specifications for Integration}

Integration, in the context of Web Services Security, is the federation of identities and uniform authorization policies. Federation is the integration of trust domains across organizational boundaries and is addressed by WS-Federation. Authorization is the unification of access control policies across organizational boundaries and is addressed by WS-Authorization.

WS-Federation

WS-Federation enables the establishment of federated trust using WS-Security, WS-Policy, WS-Trust, and WS-SecureConversation as composable building blocks. Federation in this context means that a group of organizations that will have communicating Web services agrees on a uniform set of standards and policies about identification and authentication of entities for the purpose of translating one entity’s security tokens into another type of security token. For example, WS-Federation solves the problem of one organization using Kerberos and the other with which it wants to communicate using X.509. WS-Policy and WS-Trust are used to determine which tokens are consumed and how to apply for tokens from an external service.

Figure 9.4 illustrates one way the WS-Trust model may be applied to simple federation scenarios. Here, security tokens (1) from the requestor’s trust realm are used to acquire security tokens from the resource’s trust realm (2) to access the resource/service (3). That is, a token from one Security Token Service (STS) is exchanged for another at a second STS (or possibly stamped or cross-certified by a second STS).

Next, Figure 9.5 shows the detailed sequence of steps used to exchange security tokens between a requestor Web service and the Web service provider resource.

Trust, Access Control, and Rights for Web Services

Figure 9.4  Simple federation scenario allowing requestor in one trust domain to interact with a resource in a different trust domain using different security models.

Trust, Access Control, and Rights for Web Services

Figure 9.5  Eight-step process used in WS-Federation to cross different trust domains with a security token.

This process is as follows:

  1. Acquire policy.

    If the requestor doesn’t already have the policy for the service, it can obtain the policy using the mechanisms defined in WS-MetadataExchange. WS-MetadataExchange allows a service to directly obtain information using WSDL, or it may choose to use a UDDI service that aggregates this information for multiple target services.

  2. Return policy.

    The requested policy is returned using the mechanisms defined in WS-MetadataExchange.

  3. Request security token.

    The requestor requests a security token from its IP/STS (assuming short-lived security tokens) using the mechanisms defined in WS-Trust: <RequestSecurityToken>.

  4. Issue security token.

    The IP/STS returns a security token (and optional proof-of-possession information) using the mechanisms defined in WS-Trust: <RequestSecurityTokenResponse> and <RequestedProofToken>.

  5. Request security token.

    The requestor requests a security token from the Web services IP/STS for the target Web service using the mechanisms defined in WS-Trust: <RequestSecurityToken>. Note that this is determined via policy or some out-of-band mechanism.

  6. Return security token.

    The Web service’s IP/STS returns a token (and optionally proof-of-possession information) using the mechanisms defined in WS-Trust: <RequestSecurityTokenResponse>.

  7. Send secured request.

    The requestor sends the request to the service attaching and securing the message using the issued tokens as described in WS-Security.

  8. Return result.

    The service issues a secured reply using its security token.


WS-Federation, SAML, Liberty, and Passport - WS-Federation deals with identity in a federated Web services context. As of this writing, no specification has been published for WS-Federation, and it is not without controversy due to the Microsoft name on the specification and the questions around the Sun-sponsored Liberty Alliance project and the Microsoft-owned Passport technology.

WS-Federation is working toward compatibility with SAML as SAML tokens become one of the types of federated tokens accepted, along with X.509, Kerberos, and XrML.

That being said, it seems valuable to have a standard approach for federated trust scenarios specific to Web services that is independent of the Liberty Alliance and Passport and generalized enough to fit into both models of identity federation.

At the very least, WS-Federation addresses a really difficult unsolved problem: how to get a Web service based in a domain using Kerberos to work effectively in a trusted fashion with a Web service based in an X.509 domain.


WS-Authorization

WS-Authorization deals with authorization decisions in the context of Web services. It describes how access policies for a Web service will be specified and managed. As of this writing, no specification has been published for WS-Authorization. Its objectives are similar to the eXtensible Access Control Markup Language (XACML) and will undoubtedly be heavily influenced by it.

SamsThis chapter is from Securing Web Services Security with WS-Security, by Jothy Rosenberg and David Remy (Sams, 2004, ISBN: 0672326515). Check it out at your favorite bookstore today.

Buy this book now.

[gp-comments width="770" linklove="off" ]

chat