Web Services Security and More: The Global XML Web Services Architecture (GXA), Page 3
XML Example: UDDI tModel and businessService
Policy expressions also can be represented as tModels within a UDDI registry, and then be associated with entities in the registry. The following example shows the creation of a UDDI tModel to represent a policy expression (the reader is referred to the UDDI specifications for more information on the UDDI structures):
<tModel tModelKey="uuid:bd3966a8-faa5-416e-9772-128554343571"> <name>http://schemas.xmlsoap.org/ws/2002/07/policytmodel</name> <description>WS-PolicyAttachment policy expression</description> </tModel>
Once this is done, the policy expression can be associated with entities in the UDDI registry through the mechanisms provided by UDDI. In the following example, the policy expression is associated with a businessService using the service's categoryBag:
<businessService> <name>MyService</name> <description>...</description> <bindingTemplates>...</bindingTemplates> <categoryBag> <keyedReference tModelKey="uuid:bd3966a8-faa5-416e-9772-128554343571" keyName="http://schemas.xmlsoap.org/ws/2002/07/policytmodel" keyValue="http://www.example.com/myservice/policy"/> </categoryBag> </tModel>
In the above example, the "tModelKey" and "keyName" attribute values below match the "tModelKey" and "name" attribute values (respectively) of the tModel shown in the previous example. This signifies that the categoryBag involves a WS-PolicyAttachment policy expression. The "keyValue" attribute value is the URI of the actual policy expression that is being associated with the businessService.
A policy expression can also be associated with a UDDI bindingTemplate, which represents an individual Web service and provides the information necessary for applications to bind to and interact with the Web service being described.
The WS-PolicyAttachment specification can be found at http://msdn.microsoft.com/ws/2002/12/PolicyAttachment.
Managing Trust Relationships: WS-Trust
All of the concepts discussed to this point are highly important, but they cannot be useful unless there is a trust relationship between two parties. This is the focus of WS-Trust specification, released in December by 2002 by Microsoft, IBM, Verisign, and RSA Security.
Trust Engine/Security Token Service
WS-Trust introduces the notion of a trust engine, a conceptual component of a Web service that evaluates the security-related aspects of a message. A trust engine verifies that:
- The claims in a security token are sufficient to comply with the policy and that the message conforms to the policy.
- The attributes of the claimant are proven by the signatures.
- The issuers of the security tokens are trusted to issue the claims they have made.
For example, if a policy stated that only Kerberos tickets were accepted as a security token, the trust engine of a Web service would enforce this requirement for all incoming messages. The WS-Trust specification also introduces the notion of a security token service that issues security tokens based on trust, similar to a certificate authority (CA).
The figure below depicts a "sender" and "receiver" Web service, each with its own trust engine. A security token service is also depicted, from which the sender Web service will request a security token to be used for its interaction with the receiver Web service. The sender Web service can request a security token based on the receiver Web service's policies, using the mechanisms described earlier in this article. The sender Web service will use its trust engine to authenticate the security token service, while the receiver Web service will use its trust engine to authenticate the sender Web service.
XML Example: Security Token Request/Response
The following example demonstrates a request for a security token (X.509 certificate), and the response with the certificate. The <wsse:BinarySecurityToken> was seen earlier in the description of the WS-Security specification.
<wsse:RequestSecurityToken> <wsse:TokenType>wsse:X509v3</wsse:TokenType> <wsse:RequestType>wsse:ReqIssue</wsse:RequestType> </wsse:RequestSecurityToken> <wsse:RequestSecurityTokenResponse> <wsse:RequestedSecurityToken> <BinarySecurityToken ValueType="wsse:X509v3" EncodingType="wsse:Base64Binary"> MIIEZzCCA9CgAwIBAgIQEmtJZc0... </BinarySecurityToken> </wsse:RequestedSecurityToken> </wsse:RequestSecurityTokenResponse>
In the above example, the <wsse:RequestType> element value of "ReqIssue" denotes the issuance of a security token. Other valid values are "ReqValidate" (validate security token) and "ReqExchange" (exchange security token).
In some cases, a security token service may choose to challenge the requestor of a security token. For example, this may occur if the security token service does not trust the nonce and timestamp (for example, the freshness) in the message. Or, the security token service may challenge the signature within the message. Challenge requests and responses are issued by specifying challenge and response elements within a <wsse:RequestSecurityTokenResponse> element, in a negotiation-type scenario.
XML Example: Signature Challenge
Signature challenges are processed using the <wsse:SignChallenge> element, as shown in the following example:
<wsse:SignChallenge> <wsse:Challenge>Describes the message parts to be signed...</wsse:Challenge> <wsse:SecurityTokenReference>...</wsse:SecurityTokenReference> </wsse:SignChallenge>
The <wsse:Challenge> element in the above example uses one of two possible mechanisms to describe the message parts to be signed: either an XPath expression, or one of several "message part selection functions" that are defined in the WS-PolicyAssertions specification. The <wsse:SecurityTokenReference> element is used to reference security tokens that are passed as part of the negotiation process. Once the sender receives this challenge, they would normally create a new signature that includes the specified message parts and return the new signature in a <wsse:SignChallengeResponse> element.
The WS-Trust specification can be found at http://msdn.microsoft.com/ws/2002/12/ws-trust.
Application-Level Routing: WS-Routing
SOAP by itself does not define an actual message path along which a SOAP message is to travel; rather, it relies on its underlying application layer protocols (such as HTTP or SMTP) to do so. However, these protocols each have their own mechanisms for defining message paths. That is, given four SOAP nodes—A, B, C, and D—a SOAP message generated by node A can indicate which parts of the message are meant for nodes B, C, and D, but not that that the message is to be sent from A to D via B and C as intermediaries. As GXA is transport-neutral, it cannot rely on SOAP's underlying application layer protocols for specifying message paths.
The WS-Routing specification leverages the concept of a "SOAP intermediary" as defined in SOAP 1.2, therefore "raising up" the capability to define a message path to the SOAP layer and making it transport-neutral. It is a simple, stateless, SOAP-based protocol for routing SOAP messages in an asynchronous manner over a variety of transports. The WS-Routing specification was released in October 2001 by Microsoft.
WS-Routing (and the WS-Referral specification, discussed next) defines the concept of a SOAP router, which is a SOAP node that exposes SOAP message relaying as a Web service either as a standalone service or in combination with other services. WS-Routing also defines a new SOAP header named <path> that contains the following elements:
- from: Denotes the message originator
- from: Denotes the ultimate receiver
- fwd: Contains the forward message path
- rev: Contains the reverse message path, enabling two-way message exchange
The <wsrp:fwd> and <wsrp:rev> elements also contain <wsrp:via> elements to denote intermediaries.
XML Example: "path" SOAP Header
The following example demonstrates a "path" SOAP header:
<SOAP-ENV:Header> <wsrp:path> <wsrp:to>soap://D.com</wsrp:to> <wsrp:fwd> <wsrp:via>soap://B.com</wsrp:via> <wsrp:via>soap://C.com</wsrp:via> </wsrp:fwd> <wsrp:from>soap://A.com</wsrp:from> <wsrp:id>uuid:84b9f5d0-33fb-4a81-b02b-5b760641c1d6</wsrp:id> </wsrp:path> </SOAP-ENV:Header>
In the above example, the message is to travel from soap://A.com to soap://D.com, passing through ("via") intermediaries soap://B.com and soap://C.com. This may be done for purposes such as load balancing, if a Web service's network address has changed, or for dynamic message path optimization (a "better" path suddenly exists).
XML Example: Reverse Paths
As the above message travels through each of the above nodes, each node may alter the "path" SOAP header to include its destination address in a <wsrp:rev> element, in case the message path needs to be reversed (for example, due to an error). In the following example, the message has just passed through node soap://A.com, and this node has entered its destination address in a <wsrp:rev> element:
<SOAP-ENV:Header> <wsrp:path> <wsrp:to>soap://D.com</wsrp:to> <wsrp:fwd> <wsrp:via>soap://B.com</wsrp:via> <wsrp:via>soap://C.com</wsrp:via> </wsrp:fwd> <wsrp:rev> <wsrp:via>soap://A.com</wsrp:via> </wsrp:rev> <wsrp:id>uuid:84b9f5d0-33fb-4a81-b02b-5b760641c1d6</wsrp:id> </wsrp:path> </SOAP-ENV:Header>
Each successive node could also do so, adding its destination address to the <wsrp:rev> element to build a complete reverse path.
The WS-Routing specification can be found at http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnglobspec/html/ws-routing.asp.