| A service description (Figure 5.8) is a set of documents that collectively describe the interface to a service (i.e., service expectations and functionalities). In addition to the interface definition, and as it implies in the name , it must describe the semantics of a service, such as the relationship between operations on a service, the meaning of an interface, and/or the basic behavior of an operation. Figure 5.8. Service description for Web services.  A service must be cohesive, and it must provide service descriptions with the details on its utilization syntax and semantics. Normally speaking, these service descriptions are intended for programmatic processing rather than human processing. A sample service description and its usage is shown in Figure 5.8, where a search engine service is exposing some of its capabilities to the external world so that its clients can understand the syntax and semantics of that service, and interact with the service. This service may then interact with other services using the description provided by those services, such as other search engines or news services. This description can be expressed in any available description languages, such as Web Service Description Language (WSDL), Dynamic Agent Markup Language (DAML [17] ), or Resource Description Framework (RDF). However, we should note that this description can be expressed in a combination of languages. One such example combination may be using WSDL for service syntax description while using RDF for service semantic description in association with WSDL. Figure 5.9 shows how this can be expressed for the above search service. Figure 5.9. Sample service description with semantic information.  Let us now explore WSDL to understand the basic constructs provided to describe a Web service. Web Service Description Language (WSDL) This discussion is based on the WSDL 1.1 specification. [18] We will cover some core concepts of WSDL 1.2, which is a work activity in the W3C. [19] Some of the WSDL 1.2 constructs are of importance to the grid services community. Quick Overview of WSDL 1.1 WSDL is an XML Infoset-based document, which provides a model and XML format for describing Web services. This enables services to be described, and enables the client to consume these services in a standard way without knowing much on the lower level protocol exchange binding including SOAP and HTTP. This high-level abstraction on the service limits human interaction and enables the automatic generation of proxies for Web services, and these proxies can be static or dynamic. WSDL allows the description of both document-oriented and RPC-oriented messages. As shown in Figure 5.10, a WSDL document can be divided into abstract definitions and agreed-upon definitions. The abstract section defines the SOAP messages in a platform-independent language and a neutral manner. The abstract definitions help to extend service definitions and enhance the reusability where the agreed-upon definition enables multiple protocol bindings such as HTTP and SMTP and end points of choice (e.g., service end points). The abstract service definition components are Types, Messages, Operations, PortType, and Binding. Agreed-upon definition components are Service, Port, and Binding. These agreed-upon definitions specify the wire message serialization, transport selection, and other protocol implementation aspects. The WSDL binding elements are used to specify the agreed-upon grammar for input, output, and fault messages. There are specific binding extensions defined by WSDL for SOAP and HTTP. Figure 5.10. The WSDL 1.1 abstract and agreed-upon components.  There can be two kinds of message encoding; that is, literal encoding and SOAP encoding. Literal encoding specifies that the messages will be constructed according to the XML schema "literal," and SOAP encoding occurs according to the SOAP-encoding rules "encoded," defined in the SOAP specification. The other important concepts in WSDL are the message transfer format; messages can be transferred as "document" or "rpc" parameters. Document means that the message part is the body of the message, while RPC means that the parts are just parameters of the call, with specific signatures that are wrapped in an element. These transfer formats confirm to the SOAP semantic of the SOAP message exchange. There has been a number of limitations with this model including service semantic clarifications, extension mechanisms, and the support for new constructs in the SOAP 1.2 specification. WSDL 1.2 is trying to resolve these problems. Quick Overview of WSDL 1.2 Some of the major changes are introduced to align the WSDL 1.1 specification with the SOAP 1.2 specification, and the overall service-oriented architecture standards such as Web architecture and Web service architecture. One of the major semantic clarifications we can discuss is regarding the concept of the service . Let us explore the semantic details of this concept. We will start with the concept of a resource. A resource is anything that can be addressable by a URI. These resources can be software applications, hardware abstractions, or Web resources (e.g., HTML pages or forms). Every resource can be logically represented by a set of interfaces, such as manageability interfaces, operational interfaces, and other such interfaces. A service is then treated as a realization of a single interface of a resource. This is represented in Figure 5.11. Figure 5.11. The WSDL 1.2 abstract and agreed-upon components.  Note that a service can have any number of end points and bindings. But every service is a representation of a single interface. This interface may be a combination of multiple interfaces through derivation. We discuss the details of the interface inheritance toward the end of this section on WSDL 1.2. This view is different from the WSDL 1.1's view, where a single service can be bound to multiple interfaces through bindings. This causes confusion on the semantic of a service. It is a fact that in WSDL 1.1, it is difficult to express service semantics through the description language. A binding may select to implement any interfaces of choice. This confusion is later clarified in WSDL 1.2 by having a service as a representation of a single interface of a resource. A service may then have multiple end points with different addresses and bindings, however, always bound to the same resource using the same interface. There is another construct introduced to clarify the resource that a service is implementing. This is done using a new construct called "targetResource." This "targetResource" is an attribute of a service element, with a URI value representing the resource URI. Based on the above discussion, a service element is defined in Listing 5.2: Listing 5.2. A service element definition in WSDL 1.2. <definitions> ..................................................................... <serviname="xs:NCName" interface="xs:QName" targetResource="xs:anyURI"? > <end-point />* </service> </definitions> We can see the WSDL 1.2 description information elements in the following illustration. The concept of "Resource" is logical. As shown in Figure 5.11, the service developers have to define the abstract concepts of a service and attach a service to the target resource and the corresponding interface. The binding selection must then be a runtime activity. In addition to the clarification on the semantic of a service, WSDL 1.2 has introduced the concept of features, properties, and so on. These concepts are in line with the SOAP 1.2 counterparts and can be extended to other protocols of choice. By defining features and properties in WSDL, a reader (i.e., software agents or humans ) can identify the following characteristics: -
Some requirements on the interface/operations for its successful execution. For example, some operations need to provide a WS-Security assertion of type XML signature. -
Some indications on the availability of some feature so that we can rely on them. For example, a service can state that a feature called "privacy policy" is available for verification. -
General information on the values of the features and its properties. These features may oftentimes appear at the interface level or at the binding level. In addition to these extensions for features and modules, there are some major changes that have been introduced, as described below. -
Operation overloading is removed from WSDL. Note that WSDL 1.1 supports the operation overloading facilities. Thus, we have to take care when designing WSDL, especially with interface inheritance. -
As we have noticed, the "PortType" construct in WSDL 1.1 is now changed to "interface" to align with the existing distributed technologies and IDL. This interface supports the inheritance capability. It is worthy to note that this extensibility of interfaces is one of the core concepts in the grid service specification. Listing 5.3 shows a sample interface hierarchy. Listing 5.3. A sample interface hierarchy provided in WSDL 1.2. <Definitions ..............> ..................................................... <interface name="A"> <operation name="add"> </operation> </interface> <interface name="B" extends="A"> <operation name="subtract"> </operation> </interface> ..................................................... </definitions> We will see the details on this interface hierarchy and its usage pattern in the next chapter during our discussion on Grid Computing. -
The "ports" construct in WSDL 1.1 has changed to "end points" in WSDL 1.2. -
Another feature that is valuable is the "mechanisms" to include other schema languages to describe the types of the message. Most notable works in this area are inclusion of DTD and RELAX-NG. -
A number of MEPs has been defined to support complex message exchange scenarios, such as request “response, input, and output. WSDL 1.2 defined these MEPs as well-defined features with specific properties. The Global XML Architecture Vision We have discussed earlier in this chapter that Web services are trying to unify software integration among partners , through advanced networking services and methods of interoperable messaging. These interoperability and integration points can be achieved only through the definition of interoperable messages, exchange patterns, and processes. The IBM Corporation, Microsoft, and a number of other vendors are working on a Global XML Architecture (GXA), which provides a modular, XML-based, open standards-based, and federated XML Web services suite. These are infrastructure-level protocols for building Web service applications. These protocols include standards for security, reliability, addressing, transactions, and multiparty agreements. The vision behind such an XML architecture includes: -
Providing standards-based and interoperable protocol definitions -
Reducing development efforts by separating infrastructure protocols from application and transport protocols -
Providing open standards-based designs for interoperable messaging across multiple vendors Based on Figure 5.12, we can further explore the basic principle of GXA. Figure 5.12. The GXA and dependencies.  The XML Data Model The core of Web services is the XML data model or the XML information set. This is defined by the W3C and forms the core of all XML specifications including SOAP and WSDL. This common base allows creation of adaptable tools and XML processors. Modularity In an earlier section, we have discussed that SOAP provides an enveloping and processing mechanism, respective to the messages being exchanged. The most common problem found with the existing protocols is the lack of the interoperable wire format. SOAP is trying to adopt a transport-independent wire format for XML messages. This is based on the SOAP encoding format as specified by the SOAP specification, or using XML schema as the wire format. The XML schema encoded messages are recommended and often called "document/literal" messages. Since XML schema is an industry standard, and based on infoset , the interoperability is essentially guaranteed . The GXA architecture is building on top of SOAP. The GXA protocols (for the most part) are SOAP extensions based on SOAP headers or features. The architecture makes use of the knowledge of SOAP intermediaries and supports SOAP actors (e.g., "role" in SOAP 1.2). Decentralization and Federation An observation we could make at this stage is that there exists the concept of constraint agreement between the parties involved in Web service integration. This agreement is on the syntax and semantics of the messages being exchanged. They may disagree on the software accepting the message, programming languages used to build the system, operating system utilized, and the database system utilized. The GXA accepted the concept of decentralization , allowing the parties involved to make their own decision on all parts of message processing including: security, policies requirements, and processing. Therefore, this concept of "federation" still allows these parties to exchange information in meaningful formats. For example, a party can exchange a message with another party, even though both disagree on the security implementation mechanisms. Application and Transport Neutral SOAP and hence GXA does not dictate on the transport mechanism for message exchange. This is a binding-level decision done by the agreement between the service and the requester. This binding agreement is independent of the message being exchanged. The application neutrality comes from the fact that it is not defining any specific message exchange protocol but instead defining standards-based XML messages that needed to be exchanged. Open Standards Initiatives Today, many of the specifications and standard protocol definitions are being submitted to various standards organizations, including OASIS and W3C. This standardization process will help to further refine these specifications and their adoptability across various heterogeneous application and protocol stacks. These standards organizations, together with the Web Service Interoperability Organization (WS-I), can provide the desired infrastructure standards the industries require to continue demonstrating progress in this area of Grid Computing and Web services. The major building blocks identified by the GXA includes facilities for: -
Message-level security -
Exchanging transaction-aware messages -
Message exchange coordination among participants -
Reliable message exchange patterns -
Message routing and referral processes -
Addressing mechanisms to dispatch messages to the intended party -
Service and message policies for proper message handling -
Attachments to foreign bodies that won't fit with regular XML messages -
Metadata information exchange Since these components are leading the way to becoming the core technology building blocks and interoperability solutions, we next explore the most commonly used components and its internal design details. In this next discussion, we explore policies, security, and addressing. Service Policy The Web service policy framework provides a general-purpose model and the corresponding syntax to describe and communicate the respective policies of a Web service. It is important to understand that this policy framework does not provide a negotiation framework for Web services. We have to use these policy building blocks in conjunction with other Web service standards and specific application-level policy negotiation services. Basically, WS-Policy enables a model and framework to express policy assertions about a Web service. These assertions are extensible grammar for expressing capabilities, requirements, and the general characteristics of a service. Note that some of these assertions may manifest into wire messages (e.g., security credentials), while some others are just information and checkpoints for service users (e.g., privacy policy). This policy model and framework defines the following components: -
Policy expression. An XML Infoset representation of one or more policy assertions. -
Policy subject. An entity (e.g., an end point, object, or resource) to which a policy can be bound. -
Policy assertion. An individual preference, requirement, capability, or other property (e.g., security, privacy, and so on). -
Policy attachment. The mechanism for associating policy with one or more subjects is referred to as a policy attachment. The following discussion will introduce us to the above components of this policy model. Listing 5.4 shows a sample policy expression, with two policy statements containing the names "QA" and "QB," respectively. It is important to pay close attention to the XML elements defined in this listing. We will also reuse this listing as a reference for the following discussion on the policy language features. Listing 5.4. A sample policy expression. <wsp:Policy xmlns:wsp="..." xmlns:wsu="..." xmlns:x="..." xml:base="http://www.acme.com/policies" wsu:Id="A" Name="QA" TargetNamespace="http://www.acme.com/policies"> <wsse:SecurityToken> <wsse:TokenType>wsse:Kerberosv5TGT</wsse:TokenType> </wsse:SecurityToken> <wsse:Integrity> <wsse:Algorithm Type="wsse:AlgSignature" URI="http://www.w3.org/2000/09/xmlenc#aes" /> </wsse:Integrity> </wsp:Policy> <wsp:Policy xmlns:wsp="..." xmlns:wsu="..." xmlns:x="..." xml:base="http://www.acme.com/policies" wsu:Id="B" Name="QB" wsp:Preference ="1" TargetNamespace="http://www.acme.com/policies"> <x:ExpeditedDelivery wsp:Usage="wsp:Required" /> </wsp:Policy> Policy Expressions and Assertions A policy expression is a mechanism to convey a set of policy assertions (e.g., security, privacy, and other policy- related items). In the above listing we are specifying a security policy assertion. A policy expression is an XML Infoset with a combination of a top level <wsp:policy> container element, the policy operators (<wsp:all>, <wsp:ExactlyOne>, <wsp:OneorMore>, and <wsp:Policy>), and some attributes (wsu:Id, Name, wsp:Preference, and so on) to distinguish the policy usage. The attributes Name and ID are used to uniquely identify the policy expression. This expression contains zero or more domain-specific assertions. These assertions can be standard defined (WS-Security assertions) and/or service provider defined (as shown in Listing 5.4). It is important to understand that the evaluations of these expressions are application-specific behavior for a given subject. We will explore later, in the policy attachment section, explanations on exactly how we can associate a policy subject with a policy expression. In the previous listing, the policy expression "QA" contains two assertions: "wsse:SecurityToken" and "wsse:Integrity." As described in the previous listing, there are two policy expressions with a default operation of <wsp:all>. This indicates that with all the policy assertions expressed, there is a present need to be satisfied. This means that for the first policy expression "QA," both the assertions "wsse:SecurityToken" and "wsse:Integrity" must be satisfied. A Mechanism for Policy Expression Attachment There are two mechanisms by which we can attach a policy expression with one or more subjects or resources. First is the XML-based resources to attach policy expressions as part of the definition. This can be done by the definition of two global XML schema attributes, as shown in Listing 5.5. Listing 5.5. A global schema attribute to define policy expression references. <xs:schema> <xs:attribute name="PolicyURIs" type="wsp:tPolicyURIs" /> <xs:attribute name="PolicyRefs" type="wsp:tPolicyRefs" /> </xs:schema> We can use the above-defined attributes to attach the policy references with a resource XML definition, as shown in Listing 5.6. Listing 5.6. An instance of a resource with the policy expression references. <MyElement xmlns:wsp="http://schemas.xmlsoap.org/ws/2002/12/policy" wsp:PolicyURIs="http://www.acme.com/policies#A http://www.acme.com/policies#B" /> This shows how to attach policy expressions to resources independently from their definition. In the above case we know the XML resource element and can change its representation. However, this may not be possible in all cases. In such cases, we need to define the policy attachment and apply that to the subject or resource of interest. Listing 5.7 shows how we can do this using the wsp:PolicyAttachment element. Listing 5.7. Policy attachment. <wsp:PolicyAttachment> <wsp:AppliesTo> <wsa:End-pointReference > <!can be any resource/service - -> </wsa:End-pointReference> </wsp:AppliesTo> <wsp:PolicyReference URI="http://www.acme.com/my-policy.xml" /> </wsp:PolicyAttachment> Listing 5.7 shows how we can attach a policy reference XML file (my-policy.xml), which contains the policy expressions to any resource identifiable through WS-Address specification End-pointReference. The developer will discover this is a more flexible approach. Interested readers could discover how these policy expressions are attached to WSDL and UDDI definition elements in WS-PolicyAttachment. [20] Also, there is some work underway to standardize some of the common sets of assertions (WS-PolicyAssertions). [21] Security Most of the existing security is dealing with point-to-point security solutions. This point-to-point security can be achieved by different ways, including SSL/TLS and IPSec as examples. Figure 5.13 shows point-to-point security establishment. Figure 5.13. Point-to-point security establishment.  As shown in Figure 5.14, Web services security involves achieving end-to-end message security between the initial sender of the message to the final receiver of the message. These messages may go through many intermediaries on the way. Figure 5.14. End-to-end security.  This message security is a combination of different levels of security requirements including end-point authentication and authorization, message integrity, message confidentiality, privacy, trust, and federation among collaborators. In general, to achieve the end-to-end security, the following points must be accommodated: -
A Web service end point can ask the requester to submit the necessary claims. -
A requester can send the message along with proof of the claim, which is normally called "security tokens" such as username/password, Kerberos tickets, and X509 certificates. -
If the requester does not have the required claims, the requestor can obtain the claims from some other trusted agency and pass these claims along with the message. These trusted authorities are called "security token services." We know that achieving the above level of security is a challenge. The GXA architecture tries to address the previous problem of security with a set of interoperable and industry-accepted standards. The following diagram shows the core security standards identified by GXA in order to achieve the required end-to-end security. Our discussions will be focused on WS-Security, [22] which forms the base security standard as illustrated in Figure 5.15. Figure 5.15. WS-Security stack with the highlighted boxes indicating the available standards.  There are a number of distributed technologies that exist today, including Kerberos, public key, and others. The widespread acceptance of these technologies helps the creators of the WS-Security specifications decide how to use them effectively in the Web services environment, instead of creating new security technologies. This decision paved the way for creating XML standards that uses existing technologies and future ones. With these requirements in mind, the WS-Security standard defines a SOAP header with a number of security assertions and meta-information . This provides quality of protection through message integrity and message confidentiality. In general, the base WS-Security specification addresses First, we will explore a basic SOAP header annotated with WS-Security information. Then, we will use this sample WS-Security header, as shown in Listing 5.8, to explain the previous add-on security constructs. Listing 5.8. WS-Security header in SOAP message. <?xml version="1.0" encoding="utf-8"?> <s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/" xmlns:wsse="http://schemas.xmlsoap.org/ws/2002/12/secext"> <s:Header> <wsse:Security> </wsse:Security> </s:Header> <s:Body> </s:Body> </s:Envelope> As we can infer from the sample skeleton, WS-Security defined its own namespace and a SOAP header with <Security> as its root element. We have previously mentioned that WS-Security addresses message integrity, which allows a receiver to be sure that the data is not tampered with in any way, and the message confidentiality and integrity is maintained . This ensures that the data cannot be compromised while in transit. WS-Security allows us to send security tokens, such as user name/password combinations, Kerberos tickets, or an X.509 certificate. We will explore each of these in the following sections. Message Integrity is a Practice to Ensure Integrity Message integrity allows a receiver to be sure that the data is not tampered with on the way to and from its origin/destination. This is normally achieved using digital signatures created using public key technologies. XML signature allows public key mechanisms. In addition, it also allows the concept of encrypting the message digest using a symmetric key (known to both parties). A message digest is a checksum on the message content created using different algorithms such as MD5. Message confidentiality means that only the intended receiver(s) can decode the received message. Others on the way cannot decode the information in the message. This confidentiality of the message exchange can be achieved using encryption mechanisms. |
Exchanging the Security Credential Information For proper authentication of the sender and receiver to occur, there needs to be an exchange of tokens showing their identity. This enables the parties to verify with whom they are exchanging information. There are a number of security tokens available, including Kerberos, signatures, and user name/password. WS-Security provides a standard mechanism for exchanging any of these credentials, along with the messages. It is important to understand that WS-Security does not address the application/service authentication process, which is an application/service run-time specific issue. While it is legal to exchange any kind of token with WS-Security, it specifies two possible kinds of tokens, summarized below. UsernameToken. Listing 5.9 presents an example of how we can pass a username and password with a WS-Security header. Listing 5.9. Passing username token with WS-Security. <wsse:Security xmlns:wsse="http://schemas.xmlsoap.org/ws/2002/12/secext"> <wsse:UsernameToken> <wsse:Username>bob</wsse:Username> <wsse:Password>x4%78r</wsse:Password> </wsse:UsernameToken> </wsse:Security> This is a very simple process of security management but may get compromised on the network transfer. In most situations these tokens are passed in an encrypted transport network connection similar to Secure Socket Layer (SSL). BinarySecurityToken. Binary tokens send tokens encoded as binary streams. These binary encoding schemes may be of different types, such as Base64 encoding. Let us explore how we can use this mechanism to send Kerberos tickets and X.509 digital signatures. These message formats are specified by the WS-Security specifications. Kerberos Tokens Listing 5.10 provides an example of how the BinarySecurityToken can be utilized to send a Kerberos ticket. Listing 5.10. Passing binary tokens with WS-Security ”Kerberos. <wsse:Security xmlns:wsse="http://schemas.xmlsoap.org/ws/2002/12/secext"> <wsse:BinarySecurityToken ValueType="wsse:Kerberosv5ST" EncodingType="wsse:Base64Binary"> WsEdUtt... </wsse:BinarySecurityToken> </wsse:Security> The above listing shows a Kerberos ticket security token embedded with the <BinarySecurityToken> element. As we can see from this example, this is not much different from the previously mentioned username token. This element ValueType attribute indicates that this is a Kerberos Version 5 service ticket, which (in this example) is utilized to authenticate this client to a particular service. X509 Certificates Listing 5.11 provides an example of how the BinarySecurityToken can be utilized to send an X509 certificate. Listing 5.11. Passing binary tokens with WS-Security ”X509 certificate. <wsse:Security xmlns:wsse="http://schemas.xmlsoap.org/ws/2002/12/secext"> <wsse:BinarySecurityToken ValueType="wsse:X509v3" EncodingType="wsse:Base64Binary"> XdfTr ... </wsse:BinarySecurityToken> </wsse:Security> The above listing illustrates how to embed an X509 certificate within the <BinarySecurityToken> element. This element ValueType attribute indicates that this is an X509 Version 3 certificate, which is used to authenticate this client to a particular service. Let us now explore a discussion regarding how to achieve message integrity using the WS-Security mechanism. Attaining Message Integrity To maintain the integrity of the SOAP message, it is required to digitally sign the XML document. The XML Signature [23] mechanism provides a standard to digitally sign XML documents (or a fragment of) the XML document. WS-Security utilizes this capability of XML Signature to maintain its message integrity. Let us discover how XML Signature works, and how WS-Security utilizes this feature to protect messages. XML Signature defines a signature element whose contents include the digital signature and the information related to that specific signature. Normally speaking, the <Signature> element used with SOAP contains the <SignedInfo>, < SignatureValue>, and <KeyInfo> elements. Listing 5.12. Using WS-Security and XML Digital Signature to protect the message integrity. <s:Envelope ............ <s:Header> <wsse:Security> <wsse:BinarySecurityToken ValueType="wsse:X509v3" EncodingType="wsse:Base64Binary" wsu:Id="X509Cert"> XdfTr... </wsse:BinarySecurityToken> <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> <ds:SignedInfo> <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14N"/> <ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/> <ds:Reference URI="#MessageBody1"> <ds:DigestMethod Algorithm= "http://www.w3.org/2000/09/xmldsig#sha1"/> <ds:DigestValue> iUtr6ou... </ds:DigestValue> </ds:Reference> </ds:SignedInfo> <ds:SignatureValue> SDRT7bHY... </ds:SignatureValue> <ds:KeyInfo> <wsse:SecurityTokenReference> <wsse:Reference URI="#X509Cert"/> </wsse:SecurityTokenReference> </ds:KeyInfo> </ds:Signature> </wsse:Security> </s:Header> <s:Body wsu:Id="MessageBody1"> </s:Body> </s:Envelope> Listing 5.12 shows a sample XML digital signature utilized with the WS-Security SOAP header in order to protect the integrity of the SOAP body identified by "MessageBody1." Considering the above listing sample, we can list the core elements of XML Signature and discover how well it fits with WS-Security and the overall SOAP message. As shown in Listing 5.12, <CanonicalizationMethod> identifies the XML canonicalization algorithm. Canonical XML The rules for XML authoring are flexible so that the same document structure and the same piece of information can be represented by different XML documents, and even XML schema or DTD can be validated from them. For example, the following two XML documents are semantically equal. However, they contain the attributes in a different order. Another item that can be noted in these documents is that the second listing contains more white space. <?xml version="1.0" ?> - <address type="US"> <zipcode value="12345" type="us-zip"/> </ address > <?xml version="1.0" ?> - <address type="US"> <zipcode type="us-zip" value="12345"/> </ address > This is a major problem with XML, as it is a text-based document and the treatment of each character may have a significant effect on the bit-by-bit validity of the document even though the document may be semantically equal. This causes problems especially when dealing with message integrity. The XML canonicalization algorithm is used to convert the XML document to a standards format, bit by bit, to avoid problems by ensuring the document will be identifiable as the same document, bit by bit, by everyone. |
In the previously illustrated example of code, you will note we are using the algorithm identified as "http://www.w3.org/2001/10/xml-exc-c14N" and defined by the W3C XML Signature working group . The <SignatureMethod> identifies the algorithm used to create the digital signature. These algorithms include the Secure Hash Algorithm (SHA) along with DSA or RSA. In the above example code we are using "RSA." The <Reference> identifies the resource to be signed. This reference may be SOAP body parts identified through message part ids (wsu:id). In addition, the reference carries the algorithm used and the digest value. In this specific example we are creating a digest using the SHA algorithm and signing the SOAP body identified as "MessageBody1." <SignatureValue> contains the real signature of the message. <KeyInfo> identifies the key that should be used to validate the above signature. This is optional provided that the recipient of the message knows how to obtain the key. In the previous discussion we mentioned that a flexible and efficient approach to achieve the XML message integrity has some problems, especially regarding the processing overhead on converting the messages to canonical format, creating the digest on that format, and adding signatures using that digest. In short, the processing required to support XML Signatures is highly process intensive . This can become complicated when we start checking the integrity of the message parts with the same (or different) algorithms. Another challenging problem is the creation of certificates and the exchange of them among the parties of interest. It is important to understand that we must exert the highest degree of care regarding these circumstances, and when we should use the XML signature. Let us now explore the topic of attaining a message exchange with confidentiality, especially in the context of end-to-end messaging transfers. How to Transfer Messages with Confidentiality The above discussed message integrity mechanism will tell us whether the message is tampered with on the way or not; however, it won't prevent someone on the message path from peeking into the message. For that we need to encrypt the XML message or fragments of the message using some standard mechanism. The XML encryption [24] standard helps us achieve this level of confidentiality. Let's discuss how the XML encryption works and how WS-Security uses that to protect our private messages. Listing 5.13 illustrates a sample SOAP message encryption mechanism using WS-Security. Listing 5.13. An encrypted XML message using WS-Security. <s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/" xmlns:wsse="http://schemas.xmlsoap.org/ws/2002/12/secext" xmlns:wsu="http://schemas.xmlsoap.org/ws/2002/07/utility" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"> <s:Header> <wsse:Security> <xenc:EncryptedKey> <xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5"/> <ds:KeyInfo> <ds:KeyName> CN=Key13, C=US </ds:KeyName> </ds:KeyInfo> <xenc:CipherData> <xenc:CipherValue> utyf^7sdf . . </xenc:CipherValue> </xenc:CipherData> <xenc:ReferenceList> <xenc:DataReference URI="#EncryptedBody1"/> </xenc:ReferenceList> </xenc:EncryptedKey> </wsse:Security> </s:Header> <s:Body> <xenc:EncryptedData wsu:Id="EncryptedBody1"> <xenc:EncryptionMethod Algorithm='http://www.w3.org/2001/04/xmlenc#tripledes-cbc'/> <xenc:CipherData> <xenc:CipherValue> WSDG^9unsV . . . </xenc:CipherValue> </xenc:CipherData> </xenc:EncryptedData> </s:Body> </s:Envelope> WS-Security utilizes three parts of the XML encryption: <EncryptedData>, <EncryptedKey>, and <ReferenceList>. Let us further examine each of these parts. <EncryptedData>. As shown in Listing 5.13, this element contains the actual encrypted data in a subelement called <CipherData>. This element can also contain subelements that indicate the encryption algorithm that was used, the key that was used in order to perform the encryption. Normally, the keys are again encrypted and will be added to the header, as shown in < EncryptedKey>. This is the case we have presented in the above sample listing. <EncryptedKey>. Similar to <EncryptedData> and in Listing 5.13, it has three subelements: <EncryptionMethod>, <KeyInfo>, and <CipherData>. The main difference lies in the fact that what is being encrypted here is a symmetric key. This header's <EncryptionMethod> describes how this key was encrypted rather than how the actual data was encrypted. The data is encrypted using the <EncryptedData> mechanism, as we have noted earlier in the text. As defined by WS-Security, XML encryption can be used in a number of ways with SOAP messages. We can encrypt the entire body, some body parts, and certain header elements, or even attachments sent with the message. The intermediaries on the path of the SOAP message can add their own encrypted headers or decryption, and process parts intended solely for themselves . Now we can define some of the higher-level security standards. We are not planning to go into details; however, we will present their usage and relationship with WS-Security. Some High-Level GXA Security Standards The high-level security standards associated with GXA are further explored in this discussion. WS-Trust We have seen earlier that the requester must possess a secure token to establish a secure message channel to the Web service end point. There may be cases where the requestor or the service may need to request tokens from other trusted parties, called secure token services. These requests for tokens, and the issuance of security tokens and trust relationship management aspects, are specified in the WS-Trust specification. [25] As shown in Figure 5.16, the WS-Trust deals with different aspects of secure token services, including how to request a token and the issuing of tokens in a trusted manner. This issuance of tokens must be secure and built on top of WS-Security. The secure token services can be a contact point for secure negotiation through delegation and impersonation. Figure 5.16. Secure Token services and the security token exchange.  WS-SecureConversation This specification defines extensions that build on WS-Security to provide secure communication. The mechanisms provided include provisions for establishing and sharing security contexts, and deriving session keys from security contexts (see Figure 5.17). Figure 5.17. A secure conversation using the WS-SecureConversation header.  WS-Federation WS-Federation defines mechanisms that are used to enable identity, attribute, authentication, and authorization federation across different trust environments. Thus far, we have been discussing how to achieve end-to-end security in Web service applications. Now we will explore one of the latest specifications in the GXA related to this, which addresses the end-point identification mechanism. The end-point identification is simple in most of the cases (i.e., stateless services); however, this may become more complex when the end points are stateful instances, or a realization of a combination of custom properties. We need to have a deep understanding of this specification since it is going to be utilized in all other specifications to address the end points. Addressing (WS-Addressing) WS-Addressing (WSA) [26] provides transport-neutral mechanisms to address Web services and messages. This capability is provided by the specification using two constructs: -
A flexible and extendable end-point reference description model -
A set of SOAP message headers (SOAP features) and rules to map the above reference elements to the header elements Normally speaking, Web services are invoked by the WSDL-provided service end-point information. For example, WSDL service ports have a location address, which identifies the end point. This information is suitable in most of the cases until we start exploring stateful Web services and/or adding more dynamic information to the address (e.g., instance information, policy constructs, etc.). This requires a client or runtime system to uniquely identify a service at runtime based on this runtime information. These elements of binding specific information on the address may include a primary key, unique identifier, and other key elements. Currently, there is no standard way that this information can be exchanged, and the mapping of that exchanged information to the run-time engine while accessing the service. In general, the current WSDL 1.1 is not suitable for the following situations: -
Dynamic generation and customization of the service end-point descriptions -
Identification and description of specific service instances that are created as the result of stateful interactions -
Flexible and dynamic exchange of end-point information The WS-Addressing specification tries to solve the above problem by providing a lightweight mechanism for identifying and describing end-point information, and mapping that information to the SOAP message headers. Listing 5.14 illustrates how to define a sample end-point description using the WS-Addressing specification. Listing 5.14. A sample WS-Address end-point identification mechanism. <wsa:End-pointReference xmlns:wsa="..." xmlns:acme="..." xmlns:ogsi="..."> <wsa:Address>http://www.acme.com/base</wsa:Address> <wsa:ReferenceProperties> <ogsi:instanceOf>myService</ogsi: instanceOf > </wsa:ReferenceProperties> <wsa:PortType>acme:AcmeSearchPortType</wsa:PortType> </wsa:End-pointReference> As shown in the preceding listing, a WSA-defined End-pointReference contains a number of subelements, such as <Address>, <ReferenceProperties>, <PortType>, <ServiceName>, and WS-Policy. The <Address> element is a URI that identifies the end point. This end point may be a network address or logical address. We can infer from the specification that with the exception of the <Address> subelement, all other subelements are optional. Based on the service end point requirements, these elements may appear in the description. As shown in the above sample listing, our Acme service end point needs some reference properties, which uniquely identifies this instance of Acme service. We can have any number of reference properties and the usability of these properties is binding and runtime specific. For example, in the above case the OGSI runtime directs the calls to the specific Acme service instance identified by "myService." The PortType is another optional parameter but may help the client-side binding stubs for validation on the operation, prior to making the call to the destination. We can also attach any number of WS-Policy expressions, along with this end point, to further qualify the end point. The above discussion helps to clarify that WS-Addressing provides much more information, and is rather dynamic in nature, when compared to the normal WSDL service location address. In addition to the description language, there needs to be a mechanism to bind this information with a SOAP message. In the next section, we will examine the WSA-defined message headers and how the mapping is occurring from an end point to SOAP headers. Listing 5.15 illustrates how to add a SOAP header with WSA constructs and end-point mapping. Listing 5.15. WSA with SOAP header. <S:Envelope xmlns:S="http://www.w3.org/2002/12/soap-envelope" xmlns:acme="..." xmlns:ogsi="..."> <S:Header> ... <wsa:To> http://www.acme.com/base</wsa:To> <ogsi:instanceOf>123456789</ogsi: instanceOf > ... </S:Header> <S:Body> ... </S:Body> </S:Envelope> The preceding listing shows how the service end-point description, defined in the previous listing, is actually mapped into the SOAP headers. The most important mapping is the mapping of <Address> maps to <To> element, which is a required element. The reference properties are copied as header elements. This, in turn , enables the SOAP processors to handle them. The Significance of WS-Addressing in the Context of Grid Services Grid services created using the OGSI standard, which we will cover later in the book in greater detail, faces the same problem of instance addressing. Currently, the grid service instance lookup is handled in two steps. First, the resolution process where it is establishing a handle resolution to convert the grid service unique handle (GSH) to a service reference. This may result in a dynamic grid service reference (GSR) with the current address of the service instance information embedded in the SOAP address location, and in some cases, in the newly defined <instanceOf> WSDL element. This dynamic is an OGSI platform-specific solution, and the tools have to be built to handle and map this dynamically generated address to the stub. WS-Addressing can avoid this problem when the end-point reference is constructed such that it is rich enough to carry the specific instance address with its associated properties. These can be directly mapped to SOAP headers as specified by the WSA specification. This enables any client-side framework that is capable of working with the stateful service. | 