Web Services Security and More, Part 2: The Global XML Web Services Architecture (GXA)
The use of derived keys in a multi-message exchange allows a different key to be used for each exchange, further enhancing security. Each successive key is derived from a key that was used on a previous exchange within the communications session. While there exist multiple algorithms for key derivation, WS-SecureConversation defines an algorithm that is a subset of the mechanism defined for TLS in RFC 2246. This algorithm uses a pseudorandom function called P_SHA-1 (pseudorandom functions are commonly used for encryption, key generation, message-authentication and challenge-response protocols). Both parties use this function to generate shared keys as needed. This function is of the following format:
P_SHA1 (secret, label + seed)
where secret is the shared secret, label is the concatenation of the client's and service's labels (as defined in their respective policies), and seed is the concatenation of the initiator's and receiver's exchanged nonce values.
<DerivedKeyToken> <SecurityTokenReference> ... </SecurityTokenReference> <Generation>4</Generation> </DerivedKeyToken>
If a new key is to be derived based on this derived key, the above <DerivedKeyToken> element would be passed to the P_SHA-1 function as the secret parameter.
The WS-SecureConversation specification can be found at
Web Services Inspection Language: WS-Inspection
Registry specifications such as Universal Description, Discovery, and Integration (UDDI), and OASIS/ebXML Registry enable the registration and discovery of Web service description documents, such as WSDL documents. Once discovered, these description documents can be utilized in a Web services exchange. The WS-Inspection specification enables the aggregation of such description documents on a single site that is not a registry. In doing so, it allows a site to be inspected for service offerings regardless of the format of the description documents for these service offerings. The WS-Inspection specification was released in 2001 by Microsoft and IBM.
A WS-Inspection document is essentially a set of pointers to service description documents of various formats. For example, the following WS-Inspection document contains a pointer to a single WSDL document:
<inspection xmlns="http://schemas.xmlsoap.org/ws/2001/10/ inspection/"> <service> <description referencedNamespace="http://schemas.xmlsoap.org/ wsdl/" location="http://somewsdldocument.wsdl"/> </service> </inspection>
The following WS-Inspection document references a service description that resides in a UDDI registry:
<inspection xmlns="http://schemas.xmlsoap.org/ws/2001/10/ inspection/"> <service> <description referencedNamespace="urn:uddi-org:api"> <wsiluddi:serviceDescription location="http://www.descriptionlocation.com "> <wsiluddi:serviceKey>4FA28580-5C39-11D5-9FCF- AA3200333F79</wsiluddi:serviceKey> </wsiluddi:serviceDescription> </description> </service> </inspection>
In the preceding example, the "referencedNamespace" attribute identifies the namespace to which the document belongs. While the above example denotes UDDI, the value would be http://schemas.xmlsoap.org/wsdl for a description that points to a WSDL document. This attribute is provided so that WS-Inspection document consumers can easily retrieve WS-Inspection documents based on this information. Additionally, the "location" attribute provides the actual location of the description document, whereas the value of the <wsiluddi:serviceKey> element is used by a UDDI registry in conjunction with the UDDI "get_serviceDetail" message to retrieve the UDDI service description.
WS-Inspection specifies a "link" mechanism by which a WS-Inspection document can reference additional aggregations of service descriptions, such as other WS-Inspection documents. This is shown in the following example (note that the "location" attribute contains the URI of a WS-Inspection document):
<inspection xmlns="http://schemas.xmlsoap.org/ws/2001/10/ inspection/"> <wsil:link referencedNamespace="http://schemas.xmlsoap.org/wsdl" location="uri_of_ws_inspection_document"> </inspection>
This mechanism can be valuable in two ways:
- It can allow for WS-Inspection documents to processed in a hierarchical manner
- WS-Specification does not specify any sort of pattern or algorithm for doing so—it is left up to the consumer of the links.
- This is a "best of both worlds" approach in which maintenance is easier, while still allowing the information contained in the UDDI registry to be discovered through the WS-Inspection inspection process.
WS-Inspection Document Usage
WS-Inspection specifies two methods of usage for WS-Inspection documents that describe where the documents should be placed and how they should be found:
- Fixed Name
- A WS-Inspection document named "inspection.wsil" is placed wherever the most common entry points to Web sites and applications deployed on the server may be;
- Consistent file naming allows for easy inspection of sites for available services;
- WS-Inspection documents are "linked" into HTML pages through the use of a META tag whose "name" attribute includes the value "serviceInspection" and whose "content" tag specifies a URI indicating the location of a WS-Inspection document;
- This approach allows for user-defined naming of WS-Inspection documents;
HTML META tags are used to communicate information that a human visitor may not be concerned with but which is "meta" information for the page, such as a page description that can influence the description of the page in search engines. An example of the linked approach is:
<HTML> <HEAD> <META name="serviceInspection" content="firstinspectiondoc.wsil"> <META name="serviceInspection" content="secondinspectiondoc.wsil"> <META name="serviceInspection" content="thirdinspectiondoc.wsil"> </HEAD> <BODY> ... </BODY> </HTML>
WS-Inspection defines a WSDL 1.1 binding that allows for specific information within WSDL documents to be known to WS-Inspection document consumers. More specifically, the following capabilities are provided:
- Indication of the types of WSDL bindings that appear in the referenced WSDL document;
- For WSDL documents that specify multiple services, specification of which WSDL service is being referenced;
- Indication of whether or not a particular referenced WSDL document is providing endpoint information;
The following is an example of the above capabilities expressed within a single WS-Inspection document:
<inspection> <service> <description referencedNamespace="http://schemas.xmlsoap.org/ wsdl/" location="http://somewsdldocument.wsdl"> <silwsdl:reference endpointPresent="true"> <wsilwsdl:referencedService>ServiceName </wsilwsdl:referencedService> <wsilwsdl:implementedBinding>BindingName </wsilwsdl:implementedBinding> </wsilwsdl:reference> </description> </service> </inspection>
The WS-Inspection specification can be found at msdn.microsoft.com/webservices/understanding/gxa/default.aspx?pull=/library/en-us/dnglobspec/html/ws-inspection.asp.
Page 2 of 5