Understanding Web Services | Java Security Solutions

A Web Service is any service that uses standard Web protocols, conventions, and namespaces. Web Services are widely used in Business-to-Business (B2B) communications for disparate businesses to communicate with an agreed upon XML document.

Tip	You can find more information at the W3C (World Wide Web Consortium) site ( www.w3.org ), the IETF (Internet Engineering Task Force) site ( www.ietf.org ), and OASIS ( www.oasis- open .org ).

With the invention of eXtensible Markup Language (XML), the Web server now no longer need process just GUI messages, but may also take client application requests . XML was designed for document markup and has become the default standard for data transfer. XML documents are now passed between clients and a Web server. The client can format a request in an XML document to get a response from the Web server. The Web server can act as a broker for the requested data to enterprise objects. A typical message broker in a Web server could be a Java Servlet to handle the transactions from the client. The Java Servlet is a server-side component on the Web server.

The transport mechanism for the Web Service is normally HTTP, or HTTPS for secure communication. The client can communicate to the Web server using a synchronous request and reply, or even an asynchronous messaging (sending an XML document to the Web server and asking for a response at a later time). See Figure 26-2 for an overview of a Web Service.

Figure 26-2: Web Service overview

Note

To broker an object requires a translation of the XML interface into an API that the enterprise object can communicate with. An example of an enterprise object is an EJB, an ORB, or even a JMS Topic. The XML document needs to identify which object to interface with and the data to pass it; the document does not need to identify the type of object.

The XML document provides a means for different systems to use a decoupled interface from enterprise systems, while still providing a data structure to pass data through in the form of the XML document. Developers have been using architectures very similar to Web Services since XML became available. Web servers provide connectivity out of the box and XML parsers for distilling the XML document. Java provides frameworks for parsing Web Services like JDOM. Much of the work becomes defining the XML structure and defining the associated APIs that are mapped to the XML structure.

Note	JDOM is the Java optimized document object model API from jdom.org.

Because of the disparate ways in which developers have chosen to implement their designs, standards have evolved and been defined, and Web Services have become more formalized . The following three technologies have evolved to form Web Services:

Universal Description, Discovery, and Integration (UDDI) was created to be able to register the different Web Services available and provides a discovery mechanism for Web Services that are registered.
Web Service Descriptive Language (WSDL) has become a descriptive language used to define the available interfaces on a single Web Service and its end-to-end connectivity.
Protocols used to define the structure of the XML stream that the client and server use to communicate to each other. Examples of these protocols include Simple Object Access Protocol (SOAP) and XML over RPC. SOAP is the standard for encoding the request and response for the client to the Web Service interface.

These technologies are discussed later in the chapter.

Working with Web Services security

The Web Service is loosely coupled because of the XML stream. A Web Service can be synchronous or asynchronous. Because of the ease of using XML, the data structure of instructions and data can be changed into a human-readable form. Security becomes paramount because of the ease of use and because anyone can tamper with the data as long as it is not secure. The XML stream can be sent through a secure transport, such as HTTPS, PKI or SSL.

Secure transport can secure the connection between the client and the server and the data that passes between the two, but it cannot guarantee the data outside of the transport. For any security outside of the transport, the XML structure must support key exchanges, digital signatures, and encryption. Other protocols like the GSS-API can be used to accomplish some of these features.

Cross-Reference

Chapters 21 and 22 discuss HTTPS and SSL. Chapter 25 describes PKI, and the GSS-API is discussed in Chapter 17.

XML is simply the mechanism for passing data and identifying the calling objects. Other mechanisms, like key exchanges, may also be needed for encryption and authentication between the client and the server. Some of the predominant key exchanges are X.509 certificates, Diffie-Hellman, and RSA. SOAP and XML structures need these exchanges defined in order to pass keys to different Web Services, and the Web Services that provide security need these mechanisms defined. The XML becomes a defined data container.

Cross-Reference

X.509 certificates are discussed in Chapter 24. Diffie-Helman and RSA exchanges are addressed in Chapter 4.

Some of the data that it must contain may be secure. If an element in an XML file is encrypted, it must have a mechanism to identify encrypted date from readable data so that a Web Service knows that the data must be decrypted. When a Web Service decrypts data, it has to have a mechanism to get a key to decrypt the data. Key exchanges and encrypted data must be defined in a DTD.

Note	Recall - from your XML knowledge - that Document Type Defenitions (DTDs) and XML schemas are used to describe the syntax of XML documents by declaring a set of allowed elements.

Exploring XML digital signatures

The digital signature in an XML file is used to validate and sign the XML file that is transferred. The digital signature will be extended in the XML structure as an embedded addition to the XML file. To use digital signatures, encryption techniques, and key exchange in Web Services is simply a matter of mapping XML schemas with their appropriate schema standard.

Note	For digital signatures, the mapping is to a http://www.w3.org/2000/09/xmldsig structure. Likewise, the XML encryption standard is http://www/w3/org/2001/04/xmlenc . The SOAP entry into the XML block is done with the http://schemas.xmlsoap.org/soap/security/2000-12 .

The digital signature can be included to digitally sign an XML document or a Web Service that can ensure data integrity, authentication, and non- repudiation (which have been discussed throughout the book). The XML digital signature specification, http://www.w3.org/2000/09/xmldsig and RFC 3275, defines the format of the XML structure. The purpose of the XML digital signature is to provide digital signatures for data objects that can be accessed through a URI through the Web Service.

Visual items that are displayed on a Web server can be digitally signed through the XML signature along with audio files, style sheets, image files, and encoded data. Digital signatures are shown in Listing 26-1.

Listing 26-1: Digital signature

 <Signature ID?>          <SignedInfo>            <CanonicalizationMethod/>            <SignatureMethod/>            (<Reference URI? >              (<Transforms>)?              <DigestMethod>              <DigestValue>            </Reference>)+          </SignedInfo>          <SignatureValue>         (<KeyInfo>)?         (<Object ID?>)*        </Signature>

Since multiple signature blocks can exist in a given XML structure, the signature ID identifies the signature block. To ensure that the digital signature is not tampered with, a secure hash is applied to the digital signature to ensure that signature has not been changed. A digest block inside the signature is used to specify the hash information. This is achieved with the <DigestMethod> and < DigestValue > elements. The Digest section identifies the properties of the message digest. The algorithm for the message digest, such as the SHA-1 or MD5, must be identified.

Cross-Reference

MD5, secure hash, and SHA-1 are dicussed in Chapter 9.

The decryption key is stored in the KeyInfo block. The final encrypted signature value is stored in the SignatureValue element. The <Reference> element provides information used to generate the message digest. The information includes any data transformation or normalization used along the way, including canonicalization.

Tip

Canonicalization sets a document into a standard format so that sender and receiver compute the same digest. This is useful because parsers may make insignificant changes such as eliminating whitespace. Canonicalization includes encoding the document in UTF-8, normalizing attribute values, and adding default attributes to the elements. For more information visit the W3C at www.w3.org/TR/2001/REC-xml-cl4n-20010315 .

The information needs to be carried within the signature using the <Tranforms> element. The <SignatureMethod Algorithm> defines the algorithm to be used for the actual signed value. When the receiver gets the message, the signature is decrypted using the sender's public key, the verified digest, and by verifying the sender's signature.

The reference object has a type, which can be one of many types as long as the type can be referenced in the http://www.w3.org/2000/09/xmldsig specification. An example of a reference is the following:

 <Reference URI="#TimeStamp"  Type="http://www.w3.org/2000/09/xmldsig#SignatureProperties">

The URI reference object in this example is a timestamp. The type of the object can be referenced in http://www.w3.org/2000/09/xmldsig#SignatureProperties that defines the type of the object. See http://www.w3.org/2000/09/xmldsig for the supported types.

The digital signature can be associated with the XML document in multiple ways, such as:

Enveloped: This means that the signature is a child of the data being signed.
Enveloping: This means that the signature encloses the data being signed.
Detached: This means that the signature is a sibling of the element being signed. The signature is referenced by a local link, or it can be located on the network.

The application has to determine if the key is trustworthy. As with any transportation of data, the XML document can be intercepted and modified if it is not transported through a secure channel. If the <KeyInfo> field is omitted, the recipient of the XML document is expected to identify the key to be used. A mechanism supplied by Java that is mentioned is the KeyStore . The XML specifications provide mechanisms for key management described in the XKMS specification. The XKMS provides a mechanism to agree on keys through standard key algorithms.

The XML Key Management Specification (XKMS) is a specification from the W3C organization to provide the management of keys for supporting other XML specifications like the XML digital signature. XKMS provides a standard set of XML definitions; these definitions allow developers to have a trusted third party locate and provide the appropriate keys and certificates. The trusted third party acts as an intermediary so that the Web Service programmer does not need to track the availability of keys or certificates and ensure their validity.

Tip	VeriSign is one of the primary drivers of XKMS and has a Java toolkit that supports XKMS development ( www.xmltrustcenter.org/xkms/download.htm ).

XKMS provides a simple retrieving method for obtaining a decryption key from a remote source. The retrieval method is defined by XML-SIG and relies on the use of the <RetrievalMethod> within the <KeyInfo> element. The document assumes that a service exists to provide information about a given key. The following example shows the signer that indicates a Web-resident directory, www.OurkeyDir.public , where it has published information about the public key. The following lines show the use of the RetrievalMethod element:

 <ds:KeyInfo>    <ds:RetrievalMethod URI="http://www.OurkeyDir.public/Key"      Type="http://www.w3.org/2000/09/xmldsig#X509Certificate"/> </ds:KeyInfo>

For information about a public key, an application client queries a remote service, and the location service defines a set of tags for this purpose. The following code shows the <Locate> element. The <Query> element has the name of the requested key, and the <Respond> element lists the items that the client needs information on.

 <Locate>    <Query>       <ds:KeyInfo>...</ds:KeyInfo>    </Query>    <Respond>       <string>KeyName</string>       <string>KeyValue</string>    </Respond> </Locate>

The response to the client looks like the following:

 <LocateResult>    <Result>Success</Result>    <Answer>       <ds:KeyInfo>          <ds:KeyName>O=XMLTrustCernter.org OU="Crypto"                         CN="Rich"</ds:KeyName>          <ds:KeyValue>...</ds:KeyValue>       </ds:KeyInfo>    </Answer> </LocateResult>

The validation service is a trusted third party that validates a binding between a key and an attribute such as a name. The instance is given in the following query:

 <Query>       <Status>Valid</Status>       <ds:KeyInfo>          <ds:KeyName>...</ds:KeyName>          <ds:KeyValue>...</ds:KeyValue>       </ds:KeyInfo>    </Query>    <Respond>       <string>KeyName</string>       <string>KeyValue</string>    </Respond>

The validation service should produce the following results:

 <ValidateResult>    <Result>Success</Result>    <Answer>       <KeyBinding>          <Status>Valid</Status>          <KeyID>http://www.xmltrustcenter.org/assert/20010120-39</KeyID>          <ds:KeyInfo>             <ds:KeyName>...</ds:KeyName>             <ds:KeyValue>...</ds:KeyValue>          </ds:KeyInfo>          <ValidityInterval>             <NotBefore>2000-09-20T12:00:00</NotBefore>             <NotAfter>2000-10-20T12:00:00</NotAfter>          </ValidityInterval>       </KeyBinding>    </Answer> </ValidateResult>

The <Result> and <Status> elements have different meanings. The Success indicated by the <Result> element simply indicates that the request was proposed successfully by the service. The <Status> indicates the results of the processing - in this case, the result is Valid . The optional <ValidityInterval> information shows the timespan for which the validate service's results are considered valid.

Because digital certificates and keys are not unconditionally valid, they can be assigned a specific time limit, after which time they are no longer valid. XKMS also defines requests and responses for the following areas:

Key registration: Used to register a key with a third-party KMS.
Key revocation: Used to send a request to the third-party KMS to tell it that you no longer want it to manage the key on your behalf .
Key recovery: Used to recover a key when a user forgets his private key. The XML specification does not not dictate the document structure for recovering a key.

Understanding XML encryption

The XML encryption specification allows data to be encrypted in an XML document. The encrypted part of the document has two new elements: <EncryptedData> and <CipherData> . The <EncryptedData> element defines the encryption scheme to be applied. The <CipherData> element is created to contain the encrypted serialization of the <Items> element. The result can be contained in a <CipherValue> element. As an alternative, you can use the <CipherReference> element to point to another location - URI - where the cipher resides. The <EncryptionMethod> and <KeyInfo> elements are optional. Encryption is done on an as-needed basis.

Tip	The XML encryption specification is defined by http://www.w3.org/2001/04/xmlenc .

Registering Web Services with UDDI

UDDI is used to describe the Web Services available for discovering business services that organizations provide. Different types of information can be registered. First, you can register basic company information that allows your Web Service to be discovered by company-identifying information. Secondly, you can register your Web Service based on the categories it satisfies. Finally, you can register your Web Service based on its behavior and functionality.

Note	UDDI provides a worldwide registry of Web Services for advertisement, discovery, and integration purposes. For more information visit the UDDI site at www.uddi.org .

The UDDI initiative is a set of standards and specifications. For instance, version 2.0 includes:

UDDI operators: UDDI has nodes, and this specification describes the operators and data management requirements. This is not required to be supported by private registries. Most operator nodes implement user name and password for authentication; you can use other types, but they are not defined in the specification.
UDDI API: Defines the API that all UDDI registries support. It defines SOAP messages that are supported by by a UDDI registry. You use this specification, UDDI data structure specification, and the UDDI XML API schema to program to a UDDI registry.
UDDI replication: A description of the data replication process and interfaces so that replication can occur between sites.
UDDI data structures: UDDI has a set of data structures that include:
- businessEntity : for the business basic information.
- publisherAssertion : to establish public relationships between two businessEntity structures.
- businessService : which is a grouping of bindingTemplate structures.
- bindingTemplate : contains pointers to technical material and reference one or more tModel structures.
- tModel : contains pointers to the Web Service's specifications.

The Java-based APIs are not defined by the UDDI specification. However, you have a couple of choices:

JAXR: This specification defines a way for Java programs to access registries, including UDDI. JAXR is not UDDI-specific but it allows you to access different types of registries. You can find more information about JAXR at http://java.sun.com/xml/jaxr/index.html .
A custom API: You can write you own API to access the SOAP API by inserting your XML document in each SOAP message.
A third-party API: Systinet is one such solution. Systinet provides an API to UDDI that allows you to program without knowing the details of a UDDI message or SOAP.

Defining Web Service interfaces with WSDL

WSDL describes the Web Service in a standardized fashion and the Web Services endpoints. The Web Service is a server that provides specific data and responses for client requests. WSDL allows disparate clients to automatically interact with a Web Service. A WSDL file is an interface that defines parameters and constraints for runtime communication.

Tip

There are third-party tools that generate the WSDL file based on a Web Service implementation. For example, BEA's Web Logic Server 6.1 provides Ant scripts to generate WSDL based on the implementation of a Web Service (such as an EJB), and SonicXQ (from Sonic Software's) can be used to generate WSDL mapped to services (such as JMS).

A WSDL document contains elements to describe the Web Service and may contain extensions (for example for SOAP). The main elements of a WSDL document include:

<definitions> : This element is used to describe the service such as the definition of namespaces.

Note
Recall that the XML namespace recommendation defines a mechanism to handle name collisions by mapping an element prefix and a URI.
<import> : This element allows you to include documents into the WSDL document. You can have more than one <import> element in your WSDL document.

Tip
You may think of the import element as having similar functionality to the #include in C/C++.
<types> : This element is used to define the data types used in messages. The most common is an XML schema. You can have different types, and you are not constrained to just XML schemas.

Tip
Recall that an XML schema describes the syntax of an XML document; you can use XML schemas to define types and patterns that an XML document must follow.
<message> : This element allows you to model the communication mechanisms (messages and data) for the Web Service. You can model different messages, and each message may contain different parts (model with a < part > subelement). Each part can be a type or a structure. You can reference the types defined in the < types > element.

< portType >: This element defines the endpoints of a Web Service and the set of operations (via the < operation > subelement) supported by the Web Service.

Note	The operations in the < portType > element are just a definition; the actual behavior is described later - an operation may have different behaviors. The WSDL specification defines request-response , solicit-response, one-way, and notification behaviors.

<binding> : This element is the concrete definition (protocol and data format) of the <portType> elements. It is in this element that contains the binding extensions.
<service> : This element is used to describe the endpoint (described by the <port> subelement) of a service. It contains the URL of the Web Service, and it is optional.

Listing 26-2 shows a SWDL document skeleton.

Listing 26-2: A WSDL document skeleton

 <definition>          <import>*          <types> ... </types>          <message>*            <part> ... </part>*          </message>          <portType>*            <operation>*                <input> ... </input>                <output> ... <output>            </operation>          </portType>          <binding>*            <operation>*                <input> ... </input>                <output> ... <output>            </operation>          </binding>          <service>*                <port> ... </port>          <service> </definitions>

Encoding Web Services with SOAP

The Simple Object Access Protocol ( SOAP) is an XML-based protocol for representing remote procedure calls and responses. It uses small XML documents to exchange information in a distributed and decentralized manner.

Note	All SOAP messages are encoded using XML. SOAP defines two namespaces: http://schemas.xmlsoap.org/soap/envelope/ (for the envelope) and http://schemas.xmlsoap.org/soap/encoding/ ( for the SOAP serialization).

SOAP has four major components :

A SOAP envelope: This contains the body of the message. It is addressed to the Web Service that must process the envelope with some instructions on how to process the message. The Header is a generic mechanism for adding features without prior agreement between the sender and receiver. The Body contains the mandatory information (for the ultimate recipient of the message).
A transport or protocol binding: SOAP communications (sending SOAP envelopes) use bindings to low-level protocols (such as HTTP and SMTP).
Encoding rules: This is a mapping between the application data types and XML tags.
RPC mechanism: This is a mechanism to represent remote procedure calls and return values.

Listing 26-3 shows an example of a SOAP request message. This example requests the unit price of an item based on the item's UPC. Listing 26-4 displays the response.

Listing 26-3: A SOAP request message example

 <SOAP-ENV:Envelope    xmlns:SOAP-ENV = http://schemas.xmlsoap.org/soap/envelope/    SOAP-ENV:encodingStyle =     "http://schemas.xmlsoap.org/soap/encoding/">    <SOAP-ENV:Body>        <m:GetUnitPrice xmlns:m="Some-URI">          <symbol>UPC:2394287410</symbol>        </m:GetUnitPrice>    </SOAP-ENV:Body>  </SOAP-ENV:Envelope>

Listing 26-4: A SOAP message response example

 <SOAP-ENV:Envelope   xmlns:SOAP-ENV= http://schemas.xmlsoap.org/soap/envelope/    SOAP-ENV:encodingStyle =         "http://schemas.xmlsoap.org/soap/encoding/"/>   <SOAP-ENV:Body>      <m:GetUnitPriceResponse xmlns:m="TheURI">        <Price>5.75</Price>      </m:GetUnitPriceResponse>   </SOAP-ENV:Body> </SOAP-ENV:Envelope>

While the Header and Body are defined as independent elements, they are in fact related . A body entry is semantically equivalent to a header entry intended for the default actor and with a SOAP mustUnderstand attribute with a value of "1". The <SOAP-ENV: mustUnderstand> attribute tells intermediaries that they must know how to understand the header attribute or leave it unprocessed. The value of the mustUnderstand attribute is either "1" or "0". The absence of the SOAP mustUnderstand attribute is semantically equivalent to its presence with the value "0".

As a container for XML-based messages, SOAP 1.1 has responsibilities to support the use of XML-based security technologies. To achieve encryption, authorization, and authentication, an exchange of digital credentials is required. A common form of a credential is the digital certificate X.509.

Cross-Reference

The X.509 specification is described in Chapter 24.

The XML digital signature has its own namespace contained in the <ds:Signature> element. The wrapper of the signature is <SOAP-SEC:Signature> , which specifies the namespace for the signature and the intended reader of the signature. By extending the SOAP header to use the <SOAP-SEC:Signature> extension, any Web Service can add any type of digital signature to a SOAP message.

The SOAP encodingStyle global attribute can be used to indicate the serialization rules used in a SOAP message and may appear on any element. There is no default encoding defined for a SOAP message.

Table of content

Java Security Solutions

ISBN: 0764549286
EAN: 2147483647

Year: 2001
Pages: 222

Authors: Rich Helton, Johennie Helton

BUY ON AMAZON

Java I/O

OpenSSH: A Survival Guide for Secure Shell Handling (Version 1.0)

Cisco IOS in a Nutshell (In a Nutshell (OReilly))

Programming Microsoft ASP.NET 3.5

Ruby Cookbook (Cookbooks (OReilly))

The Oracle Hackers Handbook: Hacking and Defending Oracle