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.
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
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.
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:
These technologies are discussed later in the chapter. Working with Web Services securityThe 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.
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.
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.
Exploring XML digital signaturesThe 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.
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.
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.
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:
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.
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:
Understanding XML encryptionThe 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.
Registering Web Services with UDDIUDDI 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.
The UDDI initiative is a set of standards and specifications. For instance, version 2.0 includes:
The Java-based APIs are not defined by the UDDI specification. However, you have a couple of choices:
Defining Web Service interfaces with WSDLWSDL 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.
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:
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 SOAPThe 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.
SOAP has four major components :
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.
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. Java Security Solutions ISBN: 0764549286
EAN: 2147483647 Year: 2001
Pages: 222 Authors: Rich Helton, Johennie Helton
flylib.com © 2008-2017. If you may any questions please contact us: flylib@qtcs.net |