Chapter 4. Security
4.3 WS-Security
4.3.5 Other WS-* specifications supported
Additional specifications, supported by DataPower appliance and illustrated in Figure 4-13, address further security aspects:
WS-Policy: Policy framework
WS-Trust: Defines security token exchange mechanism (integrate to TIFM) WS-SecureConversation: Focuses on defining a security context
Figure 4-13 Web services security specifications supported by DataPower appliance
These specifications provide the capabilities discussed in the following sections.
WS-Policy
WS-Policy provides a flexible and extensible grammar for expressing the capabilities,
requirements, and general characteristics of entities in an XML Web services-based system. WS-Policy defines a framework and a model for the expression of these properties as policies. Policy expressions allow for both simple declarative assertions as well as more sophisticated conditional assertions.
WS-Policy defines a policy to be a collection of one or more policy assertions. Some
assertions specify traditional requirements and capabilities that will ultimately manifest on the wire (for example, authentication scheme and transport protocol selection). Some assertions specify requirements and capabilities that have no wire manifestation yet are critical to proper service selection and usage (for example, privacy policy and QoS characteristics).
WS-Policy provides a single policy grammar to allow both kinds of assertions to be reasoned about in a consistent manner. WS-Policy stops short of specifying how policies are
discovered or attached to a Web service. Other specifications are free to define
technology-specific mechanisms for associating policy with various entities and resources.
Note: This profile applies only to the use of the <ds:Signature> elements found directly
within SAML assertions, requests, and responses. Other profiles in which signatures appear elsewhere but apply to SAML content are free to define other approaches.
WS-Security
SOAP Foundation
WS-Federation
WS-Policy
WS-Authorization
WS-Privacy
WS-Trust
WS-PolicyFramework
WS-PolicyAttachments
Policy Assertions
Subsequent specifications provide profiles on WS-Policy usage within other common Web services technologies.
WS-Policy is also covered in 3.2.2, “Web Service Policy Framework (WS-Policy Framework)” on page 30.
WS-Trust
WS-Security defines the basic mechanisms for providing secure messaging. WS-Trust specification uses these base mechanisms and defines additional primitives and extensions for security token exchange to enable the issuance and dissemination of credentials within different trust domains.
The main goal of WS-Trust is to enable applications to construct trusted (SOAP) message exchanges. This trust is represented through the exchange and brokering of security tokens. This specification provides a protocol agnostic way to issue, renew, and validate these security tokens, and supports a range of security protocols.
In order to secure a communication between two parties, the two parties must exchange security credentials (either directly or indirectly). However, each party needs to determine whether it can
trust
the asserted credentials of the other party. Thus, WS-Trust adds extensions to WS-Security, which provides: Methods for issuing, renewing, and validating security tokens
Ways to establish assess the presence of and broker trust relationships
Using these extensions, applications can engage in secure communication designed to work with the general Web services framework, including WSDL service descriptions, UDDI businessServices and bindingTemplates, and SOAP or SOAP2 messages.
For a valid WS-Trust SecurityContextToken (SCT) request, a DataPower AAA policy can generate the appropriate security token response. This processing works as an on-box WS-Trust Secure Token Service (STS) that is backed by WS-SecureConversation. A WS-Trust token requires a symmetric shared secret key to initialize the security context. This processing can handle issue, renew, validate, and cancel operations against a request security token or request security token collection.
WS-SecureConversation
A requester can be authenticated by reference to an established WS-SecureConversation security context that must already exist. WS-SecureConversation credentials are taken from the WS-SecureConversation context token.
After obtaining a set of credentials that attest to the identity of the client, a DataPower AAA policy can optionally map these credentials to a more useful format by performing custom processing on the received credentials and generating a requested WS-Trust token. This
Note: The specification that makes up WS-Policy is available for download from IBM
developerWorks at:
http://www.ibm.com/developerworks/library/specification/ws-polfram/
Note: The specification that makes up WS-Trust is available for download from IBM
developerWorks at:
token can then serve as a WS-SecureConversation token. The authentication credentials can then be mapped via any following WS-SecureConversation exchange.
ID propagation across DataPower ESB via WS-Trust
The identity of the user is passed on from the integrated applications through all the hops with the request. Passing the user identity enables the front points to apply the
authentication/authorization security policies.
Figure 4-14 Identity propagation
This is a very important aspect, because as part of the request flow from service consumer to provider through the DataPower ESB, the user context needs to be maintained and the security of the identity information ensured. For example, consider a use case where a request is coming from an internal service consumer using DataPower to invoke a service provider, as shown in Figure 4-14. The request arrives carrying a username token that carries identity information for the user USER1. DataPower calls the Security Token Services provided by Tivoli Federated Identity Manager to exchange the security token format to one supported by the service provider. For example, the username token is exchanged for a Security Assertion Markup Language (SAML) token. In addition to changing token type, the Federated Identity Manager STS can map the incoming identity information to an identity suitable for the service provider, for example, the USER2 identity is mapped to the service provider identity of USER1. DataPower has built-in capability for WS-Trust to invoke the Federated Identity Manager STS.