An Operational Model and Language Support for ... - IEEE Xplore

An Operational Model and Language Support for Securing Web Services Gwan-Hwan Hwang†, Yu-Hsuan Chang‡, and Tao-Ku Chang‡ †Department of Computer Science and Information Engineering National Taiwan Normal University, Taipei, Taiwan [email protected] ‡Graduate Institute of Information and Computer Education, National Taiwan Normal University, Taipei, Taiwan [email protected], [email protected] Abstract In this paper, we propose an operational model to support the security of Web services. In addition to satisfying the basic security requirements, including authentication, confidentiality, data integrity, and nonrepudiation, the proposed model supports security mechanisms such as element-wise encryption and temporal-based element-wise digital signatures. Furthermore, the proposed model supports a flexible key specification scheme called explicit key definition, which can be used to define three different types of keys: static keys, dynamically selected keys, and keys applied to digital signatures. The service requester can determine the identity of the keys used without negotiating with the service provider. The implementation and experimental results demonstrate the feasibility of the proposed system. Keywords: Web Services, Security, XML, SOAP, WSDL, DSL

1. Introduction Web services provide a standard means of interoperation between different software applications running on diverse platforms and/or frameworks [1]. Figure 1 shows the service-oriented architecture of Web services. First, the service requester generates request message X in SOAP format according to the WSDL document obtained from the service provider or service broker (UDDI) (note that the WSDL is an XML-based language for describing Web services and how to access them). The service provider replies by verifying if the service requester is authorized to obtain the service according to its authentication policy. It then performs the operations specified in X and returns

2007 IEEE International Conference on Web Services (ICWS 2007) 0-7695-2924-0/07 $25.00 © 2007

the execution results in another SOAP document, R. Web services employ a combination of XML [2], SOAP [3], WSDL [4], and UDDI [5] technologies.

WSDL

Internet

Service broker (UDDI)

WSDL Request SOAP

Service requester

Response SOAP

X

Service provider

Authentication policy

R

Figure 1. Service-oriented architecture of Web services The internet is a public network, and hence it is vital to protect against attacks and unauthorized access to sensitive information. The XML encryption working group of the World Wide Web Consortium (W3C) [6] delivered a recommendation specification for securing XML documents using XML encryption [7]. The W3C recommendation in [8] specifies the XML rules and syntax for processing digital signatures. Related work includes language support for securing XML documents, such as the document security language [911]. SOAP functions as a transport mechanism for XML messages by allowing programs running on one operating system to communicate with programs running on another, using the HTTP protocol and XML to exchange data. However, the original SOAP version of the W3C provided no security [3]. IBM, Microsoft, and Internet security vendor VeriSign developed Web Services Security (WS-Security) as a way for Web services to work with several different security models

via SOAP extensions [12]. Security API

Security API Request SOAP (secured)


Xs

Service requester

Service provider Response SOAPsecured (secured)

Rs

Figure 2. Hardwiring the security policy in the codes of the service requester and service provider Figure 2 illustrates a scheme that employs WS-Security to secure the operation of Web services. The service requester and service provider invoke cryptographic algorithms in the security application programming interface (API). The security policy is hardwired in the codes of the service requester and service provider, and the request and response SOAPs, Xs and Rs, are secured in the form of WS-Security. Altering the security policy (e.g., the scope of encryption and signed data) requires changes to the programs in both the service requester and service provider, which is an obvious drawback. The JDeveloper environment developed by the Oracle Corporation employs this model for testing securing and adding self-signed key-pair integrity and encryption details to both the requester and provider of Web services so as to ensure that the service is used by only authorized users [13]. WS-SecurityPolicy provides a framework for defining security, privacy, and other policies on machines involved in Web services transactions [14]. The specification also allows a system to assess the requirements of policies, such as which type of authentication is needed, and is used by the service provider to publish the associated security policies. However, some technical details such as the locations and identities of the keys cannot be specified in WS-SecurityPolicy [15], and hence this information can only be obtained by prior negotiation between the service requester and service provider. This represents a type of implicit key definition. In this paper, we propose an operational model to support the security of Web services. In addition to satisfying the basic security requirements, including authentication, confidentiality, data integrity, and nonrepudiation [16], the proposed model supports security mechanisms such as element-wise encryption and temporal-based element-wise digital signatures [911]. Furthermore, our model supports a flexible key specification scheme called explicit key definition, which can be used to define three different types of keys: static keys, dynamically selected keys, and keys


applied to digital signatures * . The service requester does not need to negotiate with the service provider to determine the identity of the keys used. The proposed operational model is designed to reduce the cost of system development and maintenance in three ways: (1) by separating service implementation and specification of the security policy for Web services, (2) by using a specially designed API to support the proposed operational model, and (3) by providing a tool with a friendly graphical user interface to specify the security policy. (A)

WSSL editor

WSDL

WSSL

Internet

Key store

WSSL API

(B)

Service requester

(1)

(secured)

(6) SOAP R

Client-side proxy

WSSL API

signatures

SOAP SOAP X

WSSL

Xs

(2)

signatures

SOAP (secured)

SOAP X Server-side proxy

(5)

Rs

Key store

(3) (4) SOAP R

Service provider


Figure 3. Proposed operational model Assume that the WSDL is available and the service requester and service provider have been implemented, as shown in Figure 1. The operational model works as follows: First, the system administrator specifies the security policy in a WSSL (Web services security language) editor that reads the original WSDL document. This editor provides an interactive graphical user interface for setting up the security policy, such as the scopes of encryption and signed data, keys used, and cryptographic algorithms, and generates a document in the WSSL (see Figure 3A). The WSSL therefore constitutes the core of the proposed operational model. The service requester and service provider then have to write the client-side and server-side proxy programs, respectively. The proxy programs invoke subroutines in the WSSL API to interpret the security policy stored in the WSSL document. The API provides a convenient way for the proxy programs to set up the required keys. Since the WSSL supports explicit key definition, the required keys can be identified without negotiation between the two proxy programs. After all the required keys are obtained, the proxy program can then instruct the WSSL API to secure or desecure SOAP messages according to the instructions in the WSSL document. *

Explicit key definition is explained in detail in Section 2.1.

The WSSL API is designed so that the programmer does not have to understand the syntax or any details of the WSSL (see Figure 3B). There are six steps for securely invoking Web services in the proposed operational model: Step 1: The service requester sends SOAP document X to the client-side proxy. Step 2: The client-side proxy invokes routines in the WSSL API to generate secured SOAP document Xs. Step 3: The server-side proxy receives Xs and invokes the WSSL API to desecure it. The desecuring process includes decrypting cipher data in Xs and verifying all the digital signatures embedded in Xs. The WSSL API supports obtaining the identity of the service requester from the embedded digital signatures according to the explicit key definition in the WSSL. It can then check the obtained identity against its authentication policy. The desecured document X is sent to the service provider. Step 4: The response message is stored in SOAP document R, and this is sent to the server-side proxy. Step 5: The server-side proxy invokes routines in the WSSL API to generate secured SOAP document Rs. Step 6: The client-side proxy receives Rs and invokes routines in the WSSL API to desecure it. In addition to decrypting the cipher data in Rs, the digital signatures embedded in Rs should be verified.

service model; that is the possible service requesters are dynamic. The service-oriented architecture of Web services almost always comprises multiple service requesters that are able to make an invocation to a single service provider (see Figure 4). Also, the allowed service requesters are always dynamic. The service provider has to check the identity of the service requester according to the authentication policy to determine if it is an allowable transaction. It is unreasonable to store the group information in the WSSL document, since this information may change. In our operational model, the authentication policy supports verification of the group information. With the dynamic key definition in the WSSL, the service requester can choose to use its private key to embed digital signatures in the SOAP message (i.e., Xs in Figure 3). It is obvious that the service provider needs to obtain the public key of the service requester in order to desecure requested messages, with this public key being used to secure response SOAP document R. Internet

WSSL API Service requester 1

Key store

SOAP

WSSL API

The WSSL is defined so as to increase the flexibility in setting the security policy and to separate service implementation and the setting of security policy. The WSSL is used to specify the security policy in the request and response SOAP documents. First, it has to describe the required keys and the cryptographic algorithms used. Second, it should support element-wise encryption and temporal-based element-wise digital signatures [9-11]. Element-wise encryption allows different portions in the SOAP documents to be encrypted using different keys and algorithms. Also, each encrypted entity may have different scopes in term of XML elements. There may be several digital signatures embedded in the SOAP document, which sign different portions of it. The digest message can be obtained before or after the encryption, which is referred to as the implementation of temporal-based element-wise digital signatures. Another important feature supported by the WSSL is explicit key definition, which can be used to specify static keys, dynamically selected keys, and keys applied to digital signatures. A static key is usually the key of the service provider that can be determined statically during the construction of the WSSL document, whereas the latter two key types are usually those of the service requester that cannot be determined because the service provider offers a many-to-one


Service requester 2

Client-side proxy

signature SOAP (secured) WSSL API

Key store

SOAP

Client-side proxy

： WSSL API Service requester n

WSSL

Key store

SOAP

signature SOAP (secured)

signature SOAP (secured)

Server-side Proxy

Key store

SOAP

Service provider


Client-side proxy

Figure 4. Multiple service requests to a single service provider (many-to-one service model) In addition to the WSSL itself, we provide another two facilities to support the proposed operational model. First, we design and implement a WSSL editor for the program to specify the security policy, as shown in Figure 3A. It is always a complicated task to write WSSL source code, since the security policy contains a considerable amount of information including the keys, algorithms, scope of encryption, and signed data. Our WSSL editor provides a friendly graphical user interface in which the user specifies the security information, from which the WSSL document is generated automatically. Second, we design the WSSL API with the goal of minimizing the code that the programmer has to write in order to construct the client-side and server-side proxy programs. The WSSL API performs the actual parsing of the WSSL documents. The programmer can instruct the WSSL

API to access the desired key stores (e.g., Java key store [17]). The occurrence of multiple errors during the operations of securing and desecuring SOAP documents also needs to be handled. The securing system should be capable of enduring certain fault situations, and subsequently activating error handling routines to deal with them. For example, when one of the cryptographic keys is not available during decryption, the security application may still be able to decrypt most of the cipher texts. Since multiple endurable errors can be encountered during a single execution, the data structure of the WSSL API allows such errors to be stored in a vector. The programmer can design error handling routines based on an examination of the recorded errors. Finally, since a secured SOAP document may contain many digital signatures, the WSSL API should be able to verify all of them and report the individual results to the proxy program. The remainder of this paper is organized as follows: Section 2 describes the syntax of WSSL documents, Section 3 presents the syntax of secured SOAP documents, Section 4 presents the WSSL API, Section 5 presents our implementation and experimental results, and conclusions are drawn in Section 6.

2. Syntax of the WSSL The syntax of the WSSL document is designed according to the above-mentioned security requirements as well as the operational model shown in Figure 3. Figure 5 shows the general syntactic form of a WSSL document, which consists of the following five sections: 1. Header: Since a WSSL document is also an XML document, a WSSL document should begin with an XML declaration that specifies the version of XML being used. 2. Key definition: This section defines keys that are referred to in the security pattern section. Since the WSSL supports explicit key definition, the key definition scheme proposed in the DSL, XML encryption, and an XML digital signature is insufficient [7-11]. 3. Algorithm definition: This section defines the algorithms referred to in the security pattern section. 4. Security pattern: According to the requirements of element-wise encryption and temporal-based element-wise digital signatures, each encrypted or signed section may contain different security patterns. A security pattern contains the keys used and the associated cryptographic algorithms. 5. Communication protocol: This section consists of


two subsections (request and response) that describe how to encrypt and embed digital signatures in secured SOAP messages Xs and Rs, respectively. h1 h2 k1 k2 k3 k4 k5

:

a1 a2 a3 a4 a5

:

p1 p2 p3 p4 p5

:

c1 c2 c3 c4 c5 c6 c7 c8 c9

: :

c10 c11 c12 c13

:

Figure 5. Architecture of a WSSL document

2.1. Key Definition The WSSL supports explicit key definition. This scheme is called “explicit” because it does not require any prior negotiation between the service requester and service provider. According to the proposed operational model shown in Figure 3, the service requester obtains the WSSL document from the service provider. The location or identity of some of the keys can be present at the WSSL document, and usually these are the keys of the service provider. Each such key is referred to as a static key. However, because of the many-to-one operational model shown in Figure 4, it is impossible to identify or locate the keys of the service requesters in the WSSL document. In this case, the WSSL document should instruct the service requester to select one of its own keys. It is obvious that the selected key should satisfy the relevant specification. This key is usually used by the service requester to embed digital signatures in Xs, and is referred to as a dynamically selected key. Another problem is that the service provider may have to encrypt some of the data stored in Rs. Note that the service provider does not know the identity of the service requester until it receives Xs, which points to the need for a third key type called keys applied to signatures. The identity or location of such keys is obtained from the digital signatures embedded by the service requester in Xs. Generally speaking, the identities and locations of dynamically selected keys and keys applied to signatures are not stored in the WSSL document, but rather can only be obtained when a Web services transaction is executed. However, explicit key definition removes the need for extra negotiation between the service provider and service requester.

It is obvious that the syntax for the key definition defined in [6,7,10,11] becomes insufficient. Both XML encryption and the DSL only support definition of a static key (see Figure 6). The key definition in the WSSL is rooted with the key_definition element, which contains two attributes. The mode attribute specifies the type of key, and has three possible values (static_key, dynamically_selected_key, and key_applied_to_signature), and the key_link attribute specifies the link name of the key definition that is referred to in the security pattern section. Since the key definitions are referred to in the security pattern or digital signature section, their link names should be specified for later reference. The key_specification subelement specifies the key. If the defined keys are static or dynamically selected, they have several subelements: key_type, PKI, key_issuer, and key_subject. The key_type element specifies the type of key, which can be a private key or a certificate (see Figure 6A and B). The PKI element identifies the PKI (public key infrastructure) used. The key_issuer and key_subject elements specify the issuer and subject of the key, respectively. If the key is applied to a digital signature, only one subelement, signature_name, is used to specify the name of the digital signature (see Figure 6C). The message_to_user subelement is used to identify the actual location of the key. The client-side and server-side proxy programs can use this message to interact with the user if the information in the key_specification element is insufficient for locating the key.

(A)

(B)

(C)

certificate X.509v3 CN=tomcat,OU=ICLAB,O=NTNU, L=Taipei,S=Taiwan,C=TW This key should be your certificate of the service request. The corresponding private key is the key whose key_link is clientKeyPrivate. private_key X.509v3 CN=tomca,OU=ICLAB,O=NTNU, L=Taipei,S=Taiwan,C=TW CN=taco,OU=ICLAB,O=NTNU, L=Taipei,S=Taiwan,C=TW This key should be the private key of the service provider. request_sign

Figure 6. Examples of key definition elements

2.2. Algorithm Definition The algorithm definition section is used to define algorithms that will be executed for securing and desecuring SOAP messages. The body of this section contains multiple algorithm definitions. The defined algorithms can be used to encrypt and decrypt XML


elements, used as digest functions in generating hash codes, or to generate and verify digital signatures. In the WSSL, we adopt the algorithm definition section that appears in the DSL [10,11].

2.3. Security Pattern The security pattern definition specifies the combination of security algorithms and encryption and decryption keys. It refers to keys and to algorithm definitions in the key and algorithm definition sections (see Figure 7).

Figure 7. An example security pattern definition

2.4. Communication Protocol The security policy settings for the request and response SOAPs, Xs and Rs, are specified in this section, which includes the encryption scope and the scope of the signed data. Note that the settings are based on the security model of element-wise encryption and temporal-based digital signatures. The settings for Xs and Rs are specified in the request and response elements, respectively. 2.4.1. request and response Elements. The request and response elements share the same basic syntax, since they are used to set the security policy of a SOAP message. Thus, here we present only the syntax of the request element.

Figure 8. Examples of security_template and digital_signatures elements A

request

element contains two subelements:

and digital_signatures. The element contains the template subelement that specifies the element-wise encryption in Xs. Its syntax is identical to the transformation template definition in [10,11], and combines the XPath [18] and scope specifier (i.e., scope attribute). Figure 8 provides an example of the template element, which specifies that the element located by the XPath "/Envelope/Body/transaction/order_info/person_info" should be encrypted according to the security pattern "request_pattern2", where the encryption scope is the “element”. The digital_signatures element specifies how to embed digital signatures in Xs. Its syntax is identical to the digital signature definition in [11] (an example is provided in Figure 8). The scope of the signed data is located by the XPath to be the element of "/Envelope/Body". This also should be signed after the encryption. security_template security_template

3. Syntax of the Secured SOAP Document In this section, we present the syntax of the secured SOAP document; that is, Xs and Rs in Figure 3. First, the secured SOAP document can follow the syntax defined in WS-Security [12]. Since WS-Security employs the XML encryption and XML signature specifications, and XML encryption does not support attribute encryption, we cannot perform attribute encryption. Attribute encryption can be used to secure the SOAP message in the syntax of an encrypted element defined in the DSL [9-11] (see secureRequestSOAP(WSSL).xml). A SOAP message, its corresponding secured version obtained in WS-Security, and the corresponding WSSL document used to activate the securing procedure are shown in requestSOAP.xml, securedRequestSOAP.xml, and WSSLDoc.xml. The complete XML files of those codes are available at [20].

4. WSSL API The WSSL API is implemented in the Java programming language [19] using three Java classes: WSSLTransform, SignatureVerification, and WSSLError. The WSSLTransform class contains the main methods used to secure and desecure SOAP messages, the SignatureVerification object stores the results of the verification of all the digital signatures in the secured SOAP document, and the WSSLError class reports error messages encountered during the securing and desecuring of a SOAP message. Figure 9 lists the pseudo Java code that employs the WSSL API to secure a SOAP document, which could


represent the code of the client-side proxy. First, lines S1,1 and S1,2 instantiate an object of the WSSLTransform class. Note that the second parameter should be “WSSLTransform.REQUESTER_MODE”. The WSSL API parses the WSSL document “WSSLDoc.xml” during the instantiation of the object. Then, lines S1,3 and S1,4 instruct the WSSL API to read the SOAP message that is to be secured. Second, the proxy program obtains the required keys, which are those used to secure the SOAP message. These keys can be obtained using “getNeededKey()” (see line S2,1), and are stored in a vector. It is then necessary to set up the keys sequentially. Note that the keys may be stored in various types of media, such as a Java key store, hard disk, USB disk, or smart card. The code should first check the “mode” of the keys and obtain all of their related properties. The setting up can be performed automatically or via interaction with the user. In our example, we assume that the subprogram “USER_INTERFACE_GET_KEY” will help with this task (see line S2,10). Finally, the obtained keys should be set up by invoking “setup()” (see line S2,11). Third, we are now ready to secure the SOAP message. Line S3,1 creates an object to store the error messages. Note that it is possible for multiple errors to occur in a single operation (i.e., securing or desecuring). We can secure the SOAP message by invoking “secureSOAP()” (see line S3,2), with the secured SOAP message stored in XML tree “Node” † . Fourth, the secured SOAP message is sent to the server-side proxy, which will return the secured response message (see line S4,1). Fifth, the received secured SOAP message (i.e., Rs in Figure 3) should be desecured. Note that there is no need to again set up the required keys since this has already been done in the code segment from lines S2,1 to S2,9. The invocation of method “desecureSOAP()” desecures the SOAP message. In addition to decrypting cipher data in the secured SOAP message, this method verifies all the embedded digital signatures. The method “getSignatureVerification()”is used to obtain the results of verifying digital signatures. Since the result is stored in a vector, we can use a loop to check the individual results (see lines S6,1 to S6,8). Finally, the desecured SOAP message is sent to the service requester (see line S7,1).

S1,1 S1,2 S1,3 S1,4

†

//Obtain an instance of WSSLTransform class. //(1) "WSSLDoc.xml" is the WSSL document shown in Figure 3. //(2) The parameter WSSLTransform.REQUESTER_MODE is used for the client-side proxy. WSSLTransform wsslTransform = New WSSLTransform("WSSLDoc.xml",WSSLTransform.REQUESTER_MOD E); // Receive X from service requester Node requestSOAP = Nework.Receiver_From_Service_Requester();

The “Node” interface is the data type for the document object model defined in “org.w3c.dom.Node” [24], which represents a single node in the document tree.

wsslTransform.readSOAPMessage(requestSOAP); S2,1 S2,2 S2,3 S2,4 S2,5 S2,6 S2,7 S2,8 S2,9 S2,10 S2,11 S2,12 S2,13 S2,14 S2,15 S2,16 S2,17 S2,18 S2,19

S3,1 S3,2

S4,1 S5,1 S5,2 S5,3

S6,1 S6,2 S6,3 S6,4 S6,5 S6,6 S6,7 S6,8

S7,1

//Interact with the user to obtain the needed keys Vector neededKeys = wsslTransform.getNeededKey(); for(int i=0;i