haphanhuyngoc
Thành viên
- Tham gia
- 2/5/2011
- Bài viết
- 0
The abstract part of the description includes a set of definitions of the types used by the service - in particular, the types of the values exchanged in messages. The Java example from Section 9.2.3, whose Java interface is shown in Figure 9.7, uses the Java types int and GraphicalObject. The former (like any basic type) can be translated directly into the XML equivalent, but GraphicalObject is defined in Java in terms of the types int, String and boolean. GraphicalObject is represented in XML, for common use by heterogeneous clients, as a complexType consisting of a sequence of named XML
types including, for example:
<element name="isFilled" type="boolean"/>
<element name="originx" type="int"/>
The set of names defined within the types section of a WSDL definition is called its
target namespace. The message section of the abstract part contains a description of the set of messages exchanged. For the document style of interaction, these messages will be used directly. For the request-reply style of interaction, there are two messages for each operation, which are used to describe the operations in the interface section. The concrete part specifies how and where the service may be contacted.
The inherent modularity of a WSDL definition allows its components to be
combined in different ways - for example, the same interface may be used with different bindings or locations. The types may be defined inside the types element or they may be defined in a separate document referenced by a URI from the types element. In the latter case, the type definitions can be referenced from several different WSDL documents.
Messages or operations • In web services, all that the client and the server need is to
have a common idea about the messages to be exchanged. For a service based on the exchange of a small number of different types of document, WSDL just describes the types of the different messages to be exchanged. When a client sends one of these messages to a web service, the latter decides what operation to perform and what type of message to send back to the client on the basis of the message type received. In our Java example, two messages will be defined for each of the operations in the interface - one for the request and one for the reply. For example, Figure 9.11 shows the request and reply messages for the newShape operation, which has a single input argument of type GraphicalObject and a single output argument of type int.
For services that support several different operations, it is more effective to
specify the messages exchanged as requests for operations with arguments and their corresponding replies, allowing the service to dispatch each request to the appropriate
402 CHAPTER 9 WEB SERVICES
Figure 9.12 Message exchange patterns for WSDL operations
Name Messages sent by
Client Server Delivery Fault message
In-Out Request Reply May replace Reply
In-Only Request No fault message
Robust In-Only Request Guaranteed May be sent
Out-In Reply Request May replace Reply
Out-Only Request No fault message Robust Out-Only Request Guaranteed May send fault
operation. However, in WSDL an operation is a construct for relating request and reply messages, in contrast to the definition of an operation in a service interface.
Interface • The collection of operations belonging to a web service are grouped
together in an XML element named interface (sometimes called portType). Each operation must specify the message exchange pattern between client and server. The available options include those shown in Figure 9.12. The first one, In-Out, is the commonly used request-reply form of client-server communication. In this pattern, the reply message may be replaced with a fault message. In-Only is for one-way messages with maybe semantics and Out-Only is for oneway messages from server to client; fault messages cannot be sent with either. Robust In-Only and Robust Out-Only are the corresponding messages with guaranteed delivery; fault messages may be exchanged. Out-In is a request-reply interaction initiated by the server. WSDL 2.0 is also extensible in that organizations can introduce their own message exchange patterns if the predefined ones prove to be inadequate.
Returning to our Java example, each of the operations is defined to have an In-Out
pattern. The operation newShape is shown in Figure 9.13, using the messages defined in Figure 9.11. This definition, together with definitions of the four other operations will be enclosed in an XML interface element. An operation may also specify the fault messages that can be sent.
Figure 9.13 WSDL operation newShape
operation name = "newShape"
pattern = In-Out
input message = "tns:ShapeList_newShape"
output message = "tns:ShapeList_newShapeResponse"
tns - target namespace xsd - XML schema definitions
The names operation, pattern, input and output are defined in the XML schema for WSDL
SECTION 9.3 SERVICE DESCRIPTIONS AND IDL FOR WEB SERVICES 403
Figure 9.14 SOAP binding and service definitions
binding service
name = "ShapeListBinding" name = "MyShapeListService"
type = "tns:ShapeList"
soap:binding transport = URI
for schemas for soap/http
endpoint
name =
"ShapeListPort"
style= "rpc"
operation
name="newShape"
input
soap:body
encoding, namespace
output
soap:body
encoding, namespace
soap:operation
soapAction
binding = "tns:ShapeListBinding"
soap:address
location = service URI
The service URI is:
"https://localhost:8080/ShapeList-jaxrpc/ShapeList"
If, for example, an operation has two arguments - say, an integer and a string - there is no need to define a new data type, since these types are defined for XML schemas. However, it will be necessary to define a message that has these two parts. This message can then be used as an input or output in the definition for the operation.
Inheritance: Any WSDL interface may extend one or more other WSDL interfaces. This
is a simple form of inheritance in which an interface supports the operations of any interfaces it extends in addition to those it defines itself. Recursive definition of interfaces is not allowed; that is, if interface B extends interface A, then interface A cannot extend interface B.
Concrete part • The remaining (concrete) part of a WSDL document consists of the
binding (the choice of protocols) and the service (the choice of endpoint or server address). The two are related, since the form of address depends on the type of protocol in use. For example, a SOAP endpoint will use a URI whereas a CORBA endpoint will use a CORBA-specific object identifier.
Binding: The binding section in a WSDL document says which message formats and
form of external data representation are to be used. For example, web services frequently use SOAP, HTTP and MIME. Bindings may be associated with particular operations or
interfaces, or they may be left free for use by a variety of different web services.
Figure 9.14 shows an example of a binding enclosing a soap:binding that specifies the URL of a particular protocol for transmitting SOAP envelopes: the HTTP binding
for SOAP. Optional attributes of this element may also specify the following:
• the message exchange pattern, which may be either rpc (request-reply) or
document exchange - the default value is document;
404
9.4
CHAPTER 9 WEB SERVICES
• the XML schema for the message formats - the default is the SOAP envelope;
• the XML schema for the external data representation - the default is the SOAP
encoding of XML.
Figure 9.14 also shows the details of the bindings for one of the operations (newShape),
specifying that both the input and the output message should travel in a soap:body, using a particular encoding style, and that the operation should be transmitted as a soapAction.
Service: Each service element in a WSDL document specifies the name of the service
and one or more endpoints (or ports) where an instance of the service may be contacted. Each of the endpoint elements refers to the name of the binding in use and, in the case of a SOAP binding, uses a soap:address element to specify the URI of the service location.
Documentation • Both human- and machine-readable information may be inserted in a
documentation element at most points within a WSDL document. This information may be removed before WSDL is used for automatic processing, for example, by stub compilers.
WSDL use • Complete WSDL documents can be accessed via their URIs by clients and
servers, either directly or indirectly via a directory service such as UDDI. Tools are available for generating WSDL definitions from information provided via a graphical user interface, removing the need for users to be involved in the complex details and structure of WSDL. For example, the Web Services Description Language for Java Toolkit (WSDL4J) allows the creation, representation and manipulation of WSDL documents describing services [wsdl4j.sourceforge.org]. WSDL definitions can also be generated from interface definitions written in other languages, such as Java JAX-RPC, discussed in Section 9.2.1.
A directory service for use with web services
There are many ways in which clients can obtain service descriptions. For example, anyone providing a higher-level web service like the travel agent service discussed in Section 9.1 would almost certainly make a web page advertising the service and potential clients would come across the web page when searching for services of that type.
However, any organization that plans to base its applications on web services will
find it more convenient to use a directory service to make these services available to clients. This is the purpose of the Universal Description, Discovery and Integration service (UDDI) [Bellwood et al. 2003], which provides both a name service and a directory service (see Section 13.3). That is, WSDL service descriptions may be looked up by name (a white pages service) or by attribute (a yellow pages service). They may also be accessed directly via their URLs, which is convenient for developers who are designing client programs that use the service.
Clients may use the yellow pages approach to look up a particular category of
service, such as travel agent or bookseller, or they may use the white pages approach to look up a service with reference to the organization that provides it.
SECTION 9.4 A DIRECTORY SERVICE FOR USE WITH WEB SERVICES 405
Figure 9.15 The main UDDI data structures
businessEntity
human-readable
information
about the publisher
businessServices
businessServices
businessServices human-readable
information
bindingTemplate
bindingTemplate
about a
family of services
bindingTemplate
information
about the
URL
URL
tModel
tModel
serviceeinterfacess servic interface
key
URL
tModel
key service descriptions
key
Data structures • The data structures supporting UDDI are designed to allow all the above styles of access and can incorporate any amount of human-readable information. The data is organized in terms of the four structures shown in Figure 9.15, each of which can be accessed individually by means of an identifier called a key (apart from tModel,
which can be accessed by a URL):
businessEntity describes the organization that provides these web services, giving its
name, address and activities, etc.;
businessServices stores information about a set of instances of a web service, such as
its name and a description of its purpose (for example, travel agent or bookseller);
bindingTemplate holds the address of a web service instance and references to
service descriptions;
tModel holds service descriptions, usually WSDL documents, stored outside the
database and accessed by means of URLs.
Lookup • UDDI provides an API for looking up services based on two sets of query
operations:
• The get_xxx set of operations includes get_BusinessDetail, get_ServiceDetail,
get_bindingDetail and get_tModelDetail; they retrieve an entity corresponding to a given key.
• The find_xxx set of operations includes find_business, find_service, find_binding
and find_tModel; they retrieve the set of entities that matches a particular set of search criteria, providing a summary of names, descriptions, keys and URLs.
Thus clients in possession of a particular key may use a get_xxx operation to retrieve the
corresponding entity directly, and other clients may use browsing to assist with searches, starting with a large set of results and gradually narrowing it down. For example, they may start by using the find_business operation in order to get a list containing a summary
406
9.5
CHAPTER 9 WEB SERVICES
of information on matching providers. From this summary, the user may use the find_service operation to narrow the search by matching the sort of service required. In both cases, they will find the key of a suitable bindingTemplate and thereby find the URL for retrieving the WSDL document for a suitable service.
In addition, UDDI provides a notify/subscribe interface by which clients register
interest in a particular set of entities in a UDDI registry and get change notifications, either synchronously or asynchronously.
Publication • UDDI provides an interface for publishing and updating information
about web services. The first time that a data structure (see Figure 9.15) is published at a UDDI server, it is given a key in the form of a URI - for example, uddi:cdk5.net:213 - and that server becomes its owner.
Registries • The UDDI service is based on replicated data stored in registries. A UDDI
registry consists of one or more UDDI servers, each of which has a copy of the same set of data. The data is replicated between the members of a registry. Each of them may respond to queries and publish information. Changes to a data structure must be submitted to its owner - that is, the server at which it was first published. It is possible for an owner to pass on the ownership to another UDDI server in the same registry.
Replication scheme: The members of a registry propagate copies of data structures to one
another as follows: a server that has made changes notifies the other servers in the registry, which then request the changes. A form of vector timestamp is used to determine which of the changes should be propagated and applied. The scheme is simple in comparison with other replication schemes that use vector timestamps, such as Gossip
(Section 18.4.1) or Coda (Section 18.4.3) for two reasons:
1. All changes to a particular data structure are made at the same server.
2. Updates from a particular server are received in sequential order by the other
members, but no particular ordering is imposed between update operations made by different servers.
Interaction between servers: As described above, servers interact with one another to
carry out the replication scheme. They can also interact in order to transfer ownership of data structures. However, the response to a lookup operation is made by a single server without any interaction with other servers in the registry, unlike in the X.500 directory service (Section 13.5), in which data is partitioned between servers that cooperate with one another in finding the relevant server for a particular request.
XML security
XML security consists of a set of related W3C designs for signing, key management and encryption. It is intended for use in cooperative work over the Internet involving documents whose contents may need to be authenticated or encrypted. Typically the documents are created, exchanged, stored and then exchanged again, possibly after being modified by a series of different users.
SECTION 9.5 XML SECURITY 407
WS-Security [Kaler 2002] is another approach to security that is concerned with applying message integrity, message confidentiality and single message authentication to SOAP.
As an example of a context in which XML security would be useful, consider a
document containing a patient's medical records. Different parts of this document are used at the local doctor's surgery and at the various special clinics and hospitals visited by the patient. It will be updated by doctors, nurses and consultants making notes on the patient's condition and treatment, by administrators making appointments and by pharmacists providing medicine. Different parts of the document will be viewable by the different roles mentioned above, and possibly the patient as well. It is essential that certain parts of the document, for example, recommendations as to treatment, can be attributed to the person that made them and can be guaranteed not to have been altered.
These needs cannot be met by TLS (previously known as SSL and described in
Section 11.6.3), which is used to create a secure channel for the communication of information. It allows the processes at the two ends of the channel to negotiate as to the need for authentication or encryption and the keys and algorithms to be used, both when a channel is set up and during its lifetime. For example, data about a financial transaction might be signed and sent in the clear until sensitive information such as credit card details are to be given, at which point encryption will be applied.
To allow for the new type of usage outlined above, the security must be specified within the document itself and applied to the document rather than as a property of the channel that will convey it from one user to another.
This is possible in XML or other structured document formats, in which metadata
can be used. XML tags can be used to define the properties of the data in the document. In particular, XML security depends on new tags that can be used to indicate the beginning and end of sections of encrypted or signed data and of signatures. Once the necessary security has been applied within a document, it may be sent to a variety of different users, even by means of multicast.
Basic requirements • XML security should provide at least the same level of protection
as TLS. That is:
To be able to encrypt either an entire document or just some selected parts of it: For
example, consider the information about a financial transaction, which includes a person's name, the type of transaction and details about the credit or debit card being used. In one case, just the card details could be hidden, making it possible to identify the transaction before decrypting the record. In another case, the type of transaction could also be hidden, so that outsiders cannot tell whether it is, for example, an order or a payment.
To be able to sign either an entire document or just some selected parts of it: When
a document is intended to be used for cooperative work by a group of people, there can be some critical parts of the document that should be signed in order to guarantee that they were made by a particular person or that they have not been changed. But it is also useful to be able to have other parts that can be altered during the use of the document - these should not be signed.
408
CHAPTER 9 WEB SERVICES
Additional basic requirements • Further requirements arise from the need to store documents, possibly to modify them and then to send them on to a variety of different
recipients:
To add to a document that is already signed and to sign the result: For example, Alice
may sign a document and pass it on to Bob, who 'witnesses her signature' by adding a remark to that effect and then signing the entire document. (Section 11.1 introduces the names, including Alice and Bob, used for the protagonists in security protocols.)
To authorize different users to view different parts of a document: In the case of a
medical record, a researcher can view some particular section of the medical data, an administrator can view personal details and a doctor can view both.
To add to a document that already contains encrypted sections and to encrypt part of
the new version, possibly including some of the already encrypted sections.
The flexibility and structuring capabilities of XML notation make it possible do all of
the above, without any additions to the scheme derived from the basic requirements.
Requirements concerning algorithms • XML secure documents are signed and/or en-
crypted well in advance of any consideration as to who will be accessing them. If the originator is no longer involved, it is not possible to negotiate the protocols and whether
to use authentication or encryption. Therefore:
The standard should specify a suite of algorithms to be provided in any implementa-
tion of XML security: At least one encryption and one signature algorithm should be mandatory, to enable the widest possible interoperability. Other optional algorithms should be provided for use within smaller groups.
The algorithms used for encryption and authentication of a particular document must
be selected from that suite and the names of the algorithms in use must be referenced within the XML document itself: If the places where the document will be used cannot be predicted, then one of the required protocols should be used.
XML security defines the names of elements that can be used to specify the URI of the
algorithm in use for signing or encryption. So as to be able to select a variety of algorithms within the same XML document, an element that specifies an algorithm is
generally nested inside an element containing signed information or encrypted data.
Requirements for finding keys • When a document is created and each time that it is
updated, appropriate keys must be chosen, without any negotiation with those parties
that may access the document in the future. This leads to the following requirements:
To help the users of secure documents with finding the necessary keys: For example,
a document that includes signed data should contain information as to the public key to be used to validate the signature, such as a name that can be used to obtain the key, or a certificate. A KeyInfo element can be used for this purpose.
To make it possible for cooperating users to help one another with keys: Provided
that the KeyInfo element is not cryptographically bound to the signature itself, information may be added without breaking the digital signature. For example, suppose Alice signs a document and sends it to Bob with a KeyInfo element that specifies only the name of the key. When Bob receives the document he retrieves the information needed to validate the signature and adds this to the KeyInfo element when he passes the document to Carol.
SECTION 9.5 XML SECURITY 409
Figure 9.16 Algorithms required for XML signature
Type of algorithm
Message digest
Encoding Signature
(asymmetric)
MAC signature
(symmetric)
Canonicalization
Name of algorithm
SHA-1
base64
DSA with SHA-1 RSA with SHA-1
HMAC-SHA-1
Canonical XML
Required Required
Required Required
Recommended
Required
Required
reference
Section 11.4.3
[Freed and Borenstein 1996]
[NIST 1994]
Section 11.3.2
Section 11.4.2 and
Krawczyk et al. [1997]
Page 409
The KeyInfo element • XML security specifies a KeyInfo element for indicating the key to be used to validate a signature or to decrypt some data. It may contain, for example, certificates, the names of keys or key agreement algorithms. Its use is optional: the signer may not want to reveal any key information to all of the parties that access the document, and in some cases the application using XML security may already have access to the keys in use.
Canonical XML • Some applications may make changes that have no effect on the
actual information content of an XML document. This arises because there are a variety of different ways of representing what is logically the same XML document. For example, attributes may be in different orders and differing character encodings may be used, yet the information content is equivalent. Canonical XML [www.w3.org X] was designed for use with digital signatures, which are used to guarantee that the information content of a document has not been changed. XML elements are canonicalized before being signed and the name of the canonicalization algorithm is stored, together with the signature. This enables the same algorithm to be used when the signature is validated.
The canonical form is a standard serialization of XML as a stream of bytes. It adds
default attributes and removes superfluous schemas, putting the attributes and schema declarations in lexicographic order in each element. It uses a standard form for line breaks and the UTF-8 encoding for characters. Any two equivalent XML documents have the same canonical form.
When a subset of an XML document - say an element - is canonicalized, the
canonical form includes the ancestor context, that is, the namespaces declared and the values of the attributes. Thus when canonical XML is used in conjunction with digital signatures, the signature of an element will not pass its validation if that element is placed in a different context.
A variation of this algorithm, called Exclusive Canonical XML, omits the context
from the serialization. This could be used if the application intends a particular signed element to be used in different contexts.
Use of digital signatures in XML • The specification for digital signatures in XML
[www.w3.org XII] is a W3C recommendation that defines new XML element types to hold signatures, the names of algorithms, keys and references to signed information. The names provided in this specification are defined in the XML Signature schema which
410 CHAPTER 9 WEB SERVICES
Figure 9.17 Algorithms required for XML encryption (the algorithms in Figure 9.16 are also required)
Type of algorithm
Block cipher
Encoding
Key transport
Name of algorithm
TRIPLEDES,
AES-128, AES-256
AES-192
base64
RSA-v1.5,
RSA-OAEP
Required Required
Optional Required Required
reference
Section 11.3.1
[Freed and Borenstein 1996]
Section 11.3.2
[Kaliski and Staddon 1998]
Symmetric key wrap TRIPLEDES Required [Housley 2002]
(signature by
shared key)
Key agreement
KeyWrap,
AES-128 KeyWrap, AES-256KeyWrap
AES-192 KeyWrap
Diffie-Hellman
Optional Optional
[Rescorla, 1999]
includes the elements Signature, SignatureValue, SignedInfo and KeyInfo. Figure 9.16 shows the algorithms that must be available in an implementation of XML Signature.
Key management service • The specification of the XML key management service
[www.w3.org XIII] contains protocols for distributing and registering public keys for use in XML signatures. Although it does not require any particular public key infrastructure, the service is designed to be compatible with existing ones, for example, X.509 certificates (Section 11.4.4), SPKI (the Simple Public Key Infrastructure, Section 11.4.4) or PGP key identifiers (Pretty Good Privacy, Section 11.5.2).
Clients can use this service to find the public key of a person. For example, if Alice
wants to send an encrypted email to Bob, she can use this service to obtain his public key. In another example, Bob receives a signed document from Alice containing her
X.509 certificate and then asks the key information service to extract the public key.
XML encryption • The standard for encryption in XML is defined in a W3C
recommendation that specifies both the way to represent encrypted data in XML and the process for encrypting and decrypting it [www.w3.org XIV]. It introduces an EncryptedData element for enclosing portions of encrypted data.
Figure 9.17 specifies the encryption algorithms that should be included in an
implementation of XML encryption. Block cipher algorithms are used for encrypting the data, and base64 encoding is used in XML for representing digital signatures and encrypted data. Key transport algorithms are public key encryption algorithms designed for use in encrypting and decrypting the keys themselves.
Symmetric key wrap algorithms are shared secret key encryption algorithms
designed for encrypting and decrypting symmetric keys by means of another key. This could be used if a key were to be included in a KeyInfo element.
A key agreement algorithm allows a shared secret key to be derived from a
computation on a pair of public keys. This algorithm is made available for use by applications that need to agree a shared key without any exchange. It is not applied by the XML security system itself.
types including, for example:
<element name="isFilled" type="boolean"/>
<element name="originx" type="int"/>
The set of names defined within the types section of a WSDL definition is called its
target namespace. The message section of the abstract part contains a description of the set of messages exchanged. For the document style of interaction, these messages will be used directly. For the request-reply style of interaction, there are two messages for each operation, which are used to describe the operations in the interface section. The concrete part specifies how and where the service may be contacted.
The inherent modularity of a WSDL definition allows its components to be
combined in different ways - for example, the same interface may be used with different bindings or locations. The types may be defined inside the types element or they may be defined in a separate document referenced by a URI from the types element. In the latter case, the type definitions can be referenced from several different WSDL documents.
Messages or operations • In web services, all that the client and the server need is to
have a common idea about the messages to be exchanged. For a service based on the exchange of a small number of different types of document, WSDL just describes the types of the different messages to be exchanged. When a client sends one of these messages to a web service, the latter decides what operation to perform and what type of message to send back to the client on the basis of the message type received. In our Java example, two messages will be defined for each of the operations in the interface - one for the request and one for the reply. For example, Figure 9.11 shows the request and reply messages for the newShape operation, which has a single input argument of type GraphicalObject and a single output argument of type int.
For services that support several different operations, it is more effective to
specify the messages exchanged as requests for operations with arguments and their corresponding replies, allowing the service to dispatch each request to the appropriate
Figure 9.12 Message exchange patterns for WSDL operations
Name Messages sent by
Client Server Delivery Fault message
In-Out Request Reply May replace Reply
In-Only Request No fault message
Robust In-Only Request Guaranteed May be sent
Out-In Reply Request May replace Reply
Out-Only Request No fault message Robust Out-Only Request Guaranteed May send fault
operation. However, in WSDL an operation is a construct for relating request and reply messages, in contrast to the definition of an operation in a service interface.
Interface • The collection of operations belonging to a web service are grouped
together in an XML element named interface (sometimes called portType). Each operation must specify the message exchange pattern between client and server. The available options include those shown in Figure 9.12. The first one, In-Out, is the commonly used request-reply form of client-server communication. In this pattern, the reply message may be replaced with a fault message. In-Only is for one-way messages with maybe semantics and Out-Only is for oneway messages from server to client; fault messages cannot be sent with either. Robust In-Only and Robust Out-Only are the corresponding messages with guaranteed delivery; fault messages may be exchanged. Out-In is a request-reply interaction initiated by the server. WSDL 2.0 is also extensible in that organizations can introduce their own message exchange patterns if the predefined ones prove to be inadequate.
Returning to our Java example, each of the operations is defined to have an In-Out
pattern. The operation newShape is shown in Figure 9.13, using the messages defined in Figure 9.11. This definition, together with definitions of the four other operations will be enclosed in an XML interface element. An operation may also specify the fault messages that can be sent.
Figure 9.13 WSDL operation newShape
operation name = "newShape"
pattern = In-Out
input message = "tns:ShapeList_newShape"
output message = "tns:ShapeList_newShapeResponse"
tns - target namespace xsd - XML schema definitions
The names operation, pattern, input and output are defined in the XML schema for WSDL
Figure 9.14 SOAP binding and service definitions
binding service
name = "ShapeListBinding" name = "MyShapeListService"
type = "tns:ShapeList"
soap:binding transport = URI
for schemas for soap/http
endpoint
name =
"ShapeListPort"
style= "rpc"
operation
name="newShape"
input
soap:body
encoding, namespace
output
soap:body
encoding, namespace
soap:operation
soapAction
binding = "tns:ShapeListBinding"
soap:address
location = service URI
The service URI is:
"https://localhost:8080/ShapeList-jaxrpc/ShapeList"
If, for example, an operation has two arguments - say, an integer and a string - there is no need to define a new data type, since these types are defined for XML schemas. However, it will be necessary to define a message that has these two parts. This message can then be used as an input or output in the definition for the operation.
Inheritance: Any WSDL interface may extend one or more other WSDL interfaces. This
is a simple form of inheritance in which an interface supports the operations of any interfaces it extends in addition to those it defines itself. Recursive definition of interfaces is not allowed; that is, if interface B extends interface A, then interface A cannot extend interface B.
Concrete part • The remaining (concrete) part of a WSDL document consists of the
binding (the choice of protocols) and the service (the choice of endpoint or server address). The two are related, since the form of address depends on the type of protocol in use. For example, a SOAP endpoint will use a URI whereas a CORBA endpoint will use a CORBA-specific object identifier.
Binding: The binding section in a WSDL document says which message formats and
form of external data representation are to be used. For example, web services frequently use SOAP, HTTP and MIME. Bindings may be associated with particular operations or
interfaces, or they may be left free for use by a variety of different web services.
Figure 9.14 shows an example of a binding enclosing a soap:binding that specifies the URL of a particular protocol for transmitting SOAP envelopes: the HTTP binding
for SOAP. Optional attributes of this element may also specify the following:
• the message exchange pattern, which may be either rpc (request-reply) or
document exchange - the default value is document;
9.4
CHAPTER 9 WEB SERVICES
• the XML schema for the message formats - the default is the SOAP envelope;
• the XML schema for the external data representation - the default is the SOAP
encoding of XML.
Figure 9.14 also shows the details of the bindings for one of the operations (newShape),
specifying that both the input and the output message should travel in a soap:body, using a particular encoding style, and that the operation should be transmitted as a soapAction.
Service: Each service element in a WSDL document specifies the name of the service
and one or more endpoints (or ports) where an instance of the service may be contacted. Each of the endpoint elements refers to the name of the binding in use and, in the case of a SOAP binding, uses a soap:address element to specify the URI of the service location.
Documentation • Both human- and machine-readable information may be inserted in a
documentation element at most points within a WSDL document. This information may be removed before WSDL is used for automatic processing, for example, by stub compilers.
WSDL use • Complete WSDL documents can be accessed via their URIs by clients and
servers, either directly or indirectly via a directory service such as UDDI. Tools are available for generating WSDL definitions from information provided via a graphical user interface, removing the need for users to be involved in the complex details and structure of WSDL. For example, the Web Services Description Language for Java Toolkit (WSDL4J) allows the creation, representation and manipulation of WSDL documents describing services [wsdl4j.sourceforge.org]. WSDL definitions can also be generated from interface definitions written in other languages, such as Java JAX-RPC, discussed in Section 9.2.1.
A directory service for use with web services
There are many ways in which clients can obtain service descriptions. For example, anyone providing a higher-level web service like the travel agent service discussed in Section 9.1 would almost certainly make a web page advertising the service and potential clients would come across the web page when searching for services of that type.
However, any organization that plans to base its applications on web services will
find it more convenient to use a directory service to make these services available to clients. This is the purpose of the Universal Description, Discovery and Integration service (UDDI) [Bellwood et al. 2003], which provides both a name service and a directory service (see Section 13.3). That is, WSDL service descriptions may be looked up by name (a white pages service) or by attribute (a yellow pages service). They may also be accessed directly via their URLs, which is convenient for developers who are designing client programs that use the service.
Clients may use the yellow pages approach to look up a particular category of
service, such as travel agent or bookseller, or they may use the white pages approach to look up a service with reference to the organization that provides it.
Figure 9.15 The main UDDI data structures
businessEntity
human-readable
information
about the publisher
businessServices
businessServices
businessServices human-readable
information
bindingTemplate
bindingTemplate
about a
family of services
bindingTemplate
information
about the
URL
URL
tModel
tModel
serviceeinterfacess servic interface
key
URL
tModel
key service descriptions
key
Data structures • The data structures supporting UDDI are designed to allow all the above styles of access and can incorporate any amount of human-readable information. The data is organized in terms of the four structures shown in Figure 9.15, each of which can be accessed individually by means of an identifier called a key (apart from tModel,
which can be accessed by a URL):
businessEntity describes the organization that provides these web services, giving its
name, address and activities, etc.;
businessServices stores information about a set of instances of a web service, such as
its name and a description of its purpose (for example, travel agent or bookseller);
bindingTemplate holds the address of a web service instance and references to
service descriptions;
tModel holds service descriptions, usually WSDL documents, stored outside the
database and accessed by means of URLs.
Lookup • UDDI provides an API for looking up services based on two sets of query
operations:
• The get_xxx set of operations includes get_BusinessDetail, get_ServiceDetail,
get_bindingDetail and get_tModelDetail; they retrieve an entity corresponding to a given key.
• The find_xxx set of operations includes find_business, find_service, find_binding
and find_tModel; they retrieve the set of entities that matches a particular set of search criteria, providing a summary of names, descriptions, keys and URLs.
Thus clients in possession of a particular key may use a get_xxx operation to retrieve the
corresponding entity directly, and other clients may use browsing to assist with searches, starting with a large set of results and gradually narrowing it down. For example, they may start by using the find_business operation in order to get a list containing a summary
9.5
CHAPTER 9 WEB SERVICES
of information on matching providers. From this summary, the user may use the find_service operation to narrow the search by matching the sort of service required. In both cases, they will find the key of a suitable bindingTemplate and thereby find the URL for retrieving the WSDL document for a suitable service.
In addition, UDDI provides a notify/subscribe interface by which clients register
interest in a particular set of entities in a UDDI registry and get change notifications, either synchronously or asynchronously.
Publication • UDDI provides an interface for publishing and updating information
about web services. The first time that a data structure (see Figure 9.15) is published at a UDDI server, it is given a key in the form of a URI - for example, uddi:cdk5.net:213 - and that server becomes its owner.
Registries • The UDDI service is based on replicated data stored in registries. A UDDI
registry consists of one or more UDDI servers, each of which has a copy of the same set of data. The data is replicated between the members of a registry. Each of them may respond to queries and publish information. Changes to a data structure must be submitted to its owner - that is, the server at which it was first published. It is possible for an owner to pass on the ownership to another UDDI server in the same registry.
Replication scheme: The members of a registry propagate copies of data structures to one
another as follows: a server that has made changes notifies the other servers in the registry, which then request the changes. A form of vector timestamp is used to determine which of the changes should be propagated and applied. The scheme is simple in comparison with other replication schemes that use vector timestamps, such as Gossip
(Section 18.4.1) or Coda (Section 18.4.3) for two reasons:
1. All changes to a particular data structure are made at the same server.
2. Updates from a particular server are received in sequential order by the other
members, but no particular ordering is imposed between update operations made by different servers.
Interaction between servers: As described above, servers interact with one another to
carry out the replication scheme. They can also interact in order to transfer ownership of data structures. However, the response to a lookup operation is made by a single server without any interaction with other servers in the registry, unlike in the X.500 directory service (Section 13.5), in which data is partitioned between servers that cooperate with one another in finding the relevant server for a particular request.
XML security
XML security consists of a set of related W3C designs for signing, key management and encryption. It is intended for use in cooperative work over the Internet involving documents whose contents may need to be authenticated or encrypted. Typically the documents are created, exchanged, stored and then exchanged again, possibly after being modified by a series of different users.
WS-Security [Kaler 2002] is another approach to security that is concerned with applying message integrity, message confidentiality and single message authentication to SOAP.
As an example of a context in which XML security would be useful, consider a
document containing a patient's medical records. Different parts of this document are used at the local doctor's surgery and at the various special clinics and hospitals visited by the patient. It will be updated by doctors, nurses and consultants making notes on the patient's condition and treatment, by administrators making appointments and by pharmacists providing medicine. Different parts of the document will be viewable by the different roles mentioned above, and possibly the patient as well. It is essential that certain parts of the document, for example, recommendations as to treatment, can be attributed to the person that made them and can be guaranteed not to have been altered.
These needs cannot be met by TLS (previously known as SSL and described in
Section 11.6.3), which is used to create a secure channel for the communication of information. It allows the processes at the two ends of the channel to negotiate as to the need for authentication or encryption and the keys and algorithms to be used, both when a channel is set up and during its lifetime. For example, data about a financial transaction might be signed and sent in the clear until sensitive information such as credit card details are to be given, at which point encryption will be applied.
To allow for the new type of usage outlined above, the security must be specified within the document itself and applied to the document rather than as a property of the channel that will convey it from one user to another.
This is possible in XML or other structured document formats, in which metadata
can be used. XML tags can be used to define the properties of the data in the document. In particular, XML security depends on new tags that can be used to indicate the beginning and end of sections of encrypted or signed data and of signatures. Once the necessary security has been applied within a document, it may be sent to a variety of different users, even by means of multicast.
Basic requirements • XML security should provide at least the same level of protection
as TLS. That is:
To be able to encrypt either an entire document or just some selected parts of it: For
example, consider the information about a financial transaction, which includes a person's name, the type of transaction and details about the credit or debit card being used. In one case, just the card details could be hidden, making it possible to identify the transaction before decrypting the record. In another case, the type of transaction could also be hidden, so that outsiders cannot tell whether it is, for example, an order or a payment.
To be able to sign either an entire document or just some selected parts of it: When
a document is intended to be used for cooperative work by a group of people, there can be some critical parts of the document that should be signed in order to guarantee that they were made by a particular person or that they have not been changed. But it is also useful to be able to have other parts that can be altered during the use of the document - these should not be signed.
CHAPTER 9 WEB SERVICES
Additional basic requirements • Further requirements arise from the need to store documents, possibly to modify them and then to send them on to a variety of different
recipients:
To add to a document that is already signed and to sign the result: For example, Alice
may sign a document and pass it on to Bob, who 'witnesses her signature' by adding a remark to that effect and then signing the entire document. (Section 11.1 introduces the names, including Alice and Bob, used for the protagonists in security protocols.)
To authorize different users to view different parts of a document: In the case of a
medical record, a researcher can view some particular section of the medical data, an administrator can view personal details and a doctor can view both.
To add to a document that already contains encrypted sections and to encrypt part of
the new version, possibly including some of the already encrypted sections.
The flexibility and structuring capabilities of XML notation make it possible do all of
the above, without any additions to the scheme derived from the basic requirements.
Requirements concerning algorithms • XML secure documents are signed and/or en-
crypted well in advance of any consideration as to who will be accessing them. If the originator is no longer involved, it is not possible to negotiate the protocols and whether
to use authentication or encryption. Therefore:
The standard should specify a suite of algorithms to be provided in any implementa-
tion of XML security: At least one encryption and one signature algorithm should be mandatory, to enable the widest possible interoperability. Other optional algorithms should be provided for use within smaller groups.
The algorithms used for encryption and authentication of a particular document must
be selected from that suite and the names of the algorithms in use must be referenced within the XML document itself: If the places where the document will be used cannot be predicted, then one of the required protocols should be used.
XML security defines the names of elements that can be used to specify the URI of the
algorithm in use for signing or encryption. So as to be able to select a variety of algorithms within the same XML document, an element that specifies an algorithm is
generally nested inside an element containing signed information or encrypted data.
Requirements for finding keys • When a document is created and each time that it is
updated, appropriate keys must be chosen, without any negotiation with those parties
that may access the document in the future. This leads to the following requirements:
To help the users of secure documents with finding the necessary keys: For example,
a document that includes signed data should contain information as to the public key to be used to validate the signature, such as a name that can be used to obtain the key, or a certificate. A KeyInfo element can be used for this purpose.
To make it possible for cooperating users to help one another with keys: Provided
that the KeyInfo element is not cryptographically bound to the signature itself, information may be added without breaking the digital signature. For example, suppose Alice signs a document and sends it to Bob with a KeyInfo element that specifies only the name of the key. When Bob receives the document he retrieves the information needed to validate the signature and adds this to the KeyInfo element when he passes the document to Carol.
Figure 9.16 Algorithms required for XML signature
Type of algorithm
Message digest
Encoding Signature
(asymmetric)
MAC signature
(symmetric)
Canonicalization
Name of algorithm
SHA-1
base64
DSA with SHA-1 RSA with SHA-1
HMAC-SHA-1
Canonical XML
Required Required
Required Required
Recommended
Required
Required
reference
Section 11.4.3
[Freed and Borenstein 1996]
[NIST 1994]
Section 11.3.2
Section 11.4.2 and
Krawczyk et al. [1997]
Page 409
The KeyInfo element • XML security specifies a KeyInfo element for indicating the key to be used to validate a signature or to decrypt some data. It may contain, for example, certificates, the names of keys or key agreement algorithms. Its use is optional: the signer may not want to reveal any key information to all of the parties that access the document, and in some cases the application using XML security may already have access to the keys in use.
Canonical XML • Some applications may make changes that have no effect on the
actual information content of an XML document. This arises because there are a variety of different ways of representing what is logically the same XML document. For example, attributes may be in different orders and differing character encodings may be used, yet the information content is equivalent. Canonical XML [www.w3.org X] was designed for use with digital signatures, which are used to guarantee that the information content of a document has not been changed. XML elements are canonicalized before being signed and the name of the canonicalization algorithm is stored, together with the signature. This enables the same algorithm to be used when the signature is validated.
The canonical form is a standard serialization of XML as a stream of bytes. It adds
default attributes and removes superfluous schemas, putting the attributes and schema declarations in lexicographic order in each element. It uses a standard form for line breaks and the UTF-8 encoding for characters. Any two equivalent XML documents have the same canonical form.
When a subset of an XML document - say an element - is canonicalized, the
canonical form includes the ancestor context, that is, the namespaces declared and the values of the attributes. Thus when canonical XML is used in conjunction with digital signatures, the signature of an element will not pass its validation if that element is placed in a different context.
A variation of this algorithm, called Exclusive Canonical XML, omits the context
from the serialization. This could be used if the application intends a particular signed element to be used in different contexts.
Use of digital signatures in XML • The specification for digital signatures in XML
[www.w3.org XII] is a W3C recommendation that defines new XML element types to hold signatures, the names of algorithms, keys and references to signed information. The names provided in this specification are defined in the XML Signature schema which
Figure 9.17 Algorithms required for XML encryption (the algorithms in Figure 9.16 are also required)
Type of algorithm
Block cipher
Encoding
Key transport
Name of algorithm
TRIPLEDES,
AES-128, AES-256
AES-192
base64
RSA-v1.5,
RSA-OAEP
Required Required
Optional Required Required
reference
Section 11.3.1
[Freed and Borenstein 1996]
Section 11.3.2
[Kaliski and Staddon 1998]
Symmetric key wrap TRIPLEDES Required [Housley 2002]
(signature by
shared key)
Key agreement
KeyWrap,
AES-128 KeyWrap, AES-256KeyWrap
AES-192 KeyWrap
Diffie-Hellman
Optional Optional
[Rescorla, 1999]
includes the elements Signature, SignatureValue, SignedInfo and KeyInfo. Figure 9.16 shows the algorithms that must be available in an implementation of XML Signature.
Key management service • The specification of the XML key management service
[www.w3.org XIII] contains protocols for distributing and registering public keys for use in XML signatures. Although it does not require any particular public key infrastructure, the service is designed to be compatible with existing ones, for example, X.509 certificates (Section 11.4.4), SPKI (the Simple Public Key Infrastructure, Section 11.4.4) or PGP key identifiers (Pretty Good Privacy, Section 11.5.2).
Clients can use this service to find the public key of a person. For example, if Alice
wants to send an encrypted email to Bob, she can use this service to obtain his public key. In another example, Bob receives a signed document from Alice containing her
X.509 certificate and then asks the key information service to extract the public key.
XML encryption • The standard for encryption in XML is defined in a W3C
recommendation that specifies both the way to represent encrypted data in XML and the process for encrypting and decrypting it [www.w3.org XIV]. It introduces an EncryptedData element for enclosing portions of encrypted data.
Figure 9.17 specifies the encryption algorithms that should be included in an
implementation of XML encryption. Block cipher algorithms are used for encrypting the data, and base64 encoding is used in XML for representing digital signatures and encrypted data. Key transport algorithms are public key encryption algorithms designed for use in encrypting and decrypting the keys themselves.
Symmetric key wrap algorithms are shared secret key encryption algorithms
designed for encrypting and decrypting symmetric keys by means of another key. This could be used if a key were to be included in a KeyInfo element.
A key agreement algorithm allows a shared secret key to be derived from a
computation on a pair of public keys. This algorithm is made available for use by applications that need to agree a shared key without any exchange. It is not applied by the XML security system itself.
Hiệu chỉnh bởi quản lý:
