Paper Menu >>
Journal Menu >>
Journal of Informatio n Security, 2011, 2, 1-7 doi:10.4236/jis.2011.21001 Published Online January 2011 (http://www.SciRP.org/journal/jis) Copyright © 2011 SciRes. JIS SOAP-Based Security Interaction of Web Service in Heterogeneous Platforms* Tao Xu, Chunxiao Yi College of Computer Science and Technology, Civil Aviation University of China, Tianjin, China E-mail: txu@cauc.edu.cn, yibin128@126.com Received October 28, 2010; revised November 23, 2010; accepted December 2, 2010 Abstract With the development and application of SOA technology, security issues of Web services based on hetero- geneous platform have become increasingly prominent. The security of SOAP message is of great impor- tance to Web service security. In order to solve the security issue of heterogeneous platforms, a security processing model named SIMSA (Security Interactive Model based on SOAP and Authentication) based on SOAP and authentication is proposed in this paper. By experimental verification, the model ensures the safety of SOAP message transmission and enhances the security of Web service in heterogeneous platforms. Keywords: SOAP, Heterogeneous, Web Service, SIMSA, Security Interaction 1. Introduction With the growth of the Service-oriented Architecture (SOA) application scale, there are hundreds of services in a large company. Different services may be deployed to platforms from different vendors, and different ser- vices installed in different locations have different access rights and security policy (encryption, signature, preven- tion of attacks, etc.). How to guarantee the security of services has become hot spot in foreign research institu- tions and scholars. IBM Tokyo Re search Insti t ute (Fumi ko Satoh et al.) puts forward the best practice models and support tools for the specific service safety profile con- struction for the IBM Websphere Server according to security policy using mapping rules [1]. Microsoft Re- search in University of Cambridge (Karthikeyan Bhar- gavan et al.) [2] publishes a security policy configur ation guidance to help developers construct the security poli- cies of Web service according to security requirements. IBM Research Division in New York (Sam Weber et al.) [3] points out that there are a large number of heteroge- neous platforms and different platforms have many Web Service standards and complex technologies. Even if there is a variety of “best security practices mode”, it is still very difficult to ensure how to ach ieve the proper se- curity. Although SOA has solved the Web services called in heterogeneous platforms, and there are relevant security standards (WS-Security) of security information exchange between different platforms, WS-Security only gives an abstract framework to achieve security goals, including XML signatures, encryption, authentication and authori- zation. As for how to u se them to achiev e th e g oa l of SOA security, it presents a challenge both in theoretical and technical practices [4,5]. Authentication policies and SOAP message-based se- curity interactive study of Web services in heterogeneous platforms have been proposed in this paper. First the se- curity feature of heterogeneous platforms is analyzed, and then the details of the security interaction model of heterogeneous platform named SIMSA is given. Com- bined with concrete application examples, user authentic- cation during a Web service call as well as the safe han- dling of SOAP messages in heterogeneous platforms is achieved. The security model provides theoretical sup- port for the security interacts of Web services in hetero- geneous platforms and is verified by experiments. This model ensures the security interactions of Web service effectively. 2. Security Features of Heterogeneous Platform SOA needs a wide rang e of interoperability between ser- *This research is supported by grants from National Natural Science Foundation of China (NO. 60979011) and Tianjin Research Program o f Application Foundation and Advanced Technology (NO. 09JCYBJC 02300). T. XU ET AL. Copyright © 2011 SciRes. JIS 2 vices. In the development of Web service’s logic func- tionality, if the security features are designed, Web ser- vices will become extremely complex and service per- formance and scalability will be greatly reduced. In terms of the analysis on the security needs and consid- eration of a variety of security measures, it can not be sure whether the security components are appropriately organized and whether the system is more secure [6,7]. Security issues of Web services in SOA should be out of service functions, and the security requirements of Web services can be achieved through appropriate security configuration and mechanism. In this way, it can not only ensure the simplicity of design and call of Web ser- vices, but also can achieve the security of SOAP mes- saging [8,9]. An application system is usually based on a platform such as Microsoft. NET or Apache Axis. The service platform has its own security solution such as Micro- soft’s WSE (Web Service Enhancement) and Axis’s of Rampart, etc. For the same security policy such as using certificates to sign the message, it can be achieved in the same platform for service requester to sign the message and service provider to do signature verification. If the service requester and provider are in different platforms, the security interoperability can not be guaranteed. Each application platform has its own security mecha- nisms and security API. When using SOA to integrate enterprise application, services of different applications may be deployed in different application platforms and security requirements may be achieved by different secu- rity policy and platform technology. Then it needs an agent mechanism dealing with service security to pack- age the specific realization of platform security from the logic, so that the security SOAP information of hetero- geneous platform can be consistently understood and treatment. Security processing mechanisms of Web services in heterogeneous platform provide security policy configu- ration and security implementation method of SOAP me- ssage [4]. Security service agents use WS-Security and other specifications to achieve the following three aspe- cts of security requirements of SOAP message [10,11]: Message integrity WS-Security takes XML signature to do digital signa- ture for SOAP message to ensure that SOAP message passes through intermediate nodes without being tam- pered. Message confidentiality WS-Security uses XML Encryption to encrypt the SOAP message, so that the message sender can ensure that the contents of SOAP message can be achieved by the intended recipient uniquely. In this way, even if SOAP messages are listened, listeners can not extract confiden- tial information from the messages. Message authenticity WS-Security introduces the concept of security to kens, which can represent the identity of the message sender. Combined with digital signatures, the message recipient can confirm the legiti macy and au thenticity of th e SOAP message sender. 3. Security Model for Heterogeneous Web Services SIMSA Security framework and configuration strategies for het- erogeneous platforms are quite different. Therefore, in order to achieve the security interaction of Web service in heterogeneous platforms, a third-party certification ag- ency must be added. It can complete the relevant certi- fication according to the request of the client. After the verification, client could send a request to call the Web service. To ensure the safety of service call process, both the client and Web server set the security service agent module to conduct safe handling to SOAP messages in the service interaction, including the signature and en- cryption of the SOAP message. The authentication mod- ule of client user is added to Web server, and only after the verification can client call the Web service. In this way, the security interactions of Web services in hetero- geneous platforms can be achieved. Combined with WS-Security specification, a security model of Web services in heterogeneous platform named SIMSA is constructed in this paper (shown in Figure 1). SIMSA model is mainly based on the extension of SOAP header including signature, encryption and authentication. The various components and functions of the security model are described as follows. 3.1. SIMSA Model Composition UDDI Server Its main function is to store service descriptions by category. It can be a private registry, such as Capecon- nect’s UDDI Registry server, or it can also be a public registry, such as IBM Corporation and Microsoft's UDDI registry. Third-Party Certification Agency It is used to verify the client’s identity information, and only the users who pass through the authentication can send service requests to the Web server. WSDL Builder It is used to describe how to use SOAP to invoke the Web service, and its function is to generate the corre- sponding WSDL document. Security Service Agent It is the core module of the model. It is respo nsible for T. XU ET AL. Copyright © 2011 SciRes. JIS 3 Figure 1. SIMSA Model. the security of Web service during transmission and ach- ieves the security requirements of the model includeing signature and encryption of the SOAP message. User Authentication Policy It is also the core module of the model. It is respon se- ble for the request verification of client’s identity, and only authenticated users can call the appropriate Web service. 3.2. Third-Party Certification Agency of SIMSA Model In order to provide reliable authentication information for the Web server, SIMSA adds a third-party certifica- tion agency. Certification agency will compare the re- questor’s information such as usernames, passwords and permissions and other information with that stored in the certification database (DB in Figure 1). It can provide users with the information needed to verify to invoke Web services. This information is encapsulated in an en- crypted message, and this message will be sent to the Web server with the user’s SOAP message, waiting for the server’s validation. In order to formally describe the process of third-party certification agency, Table 1 de- fines the parameters and function description. The formal description of certification process in third- party certification agency is shown as follows (the fol- lowing numbers correspond to that in SIMSA): 1) Client’s security service agent sends user informa- tion to the third-party certification agency: :,,CSPACSOAPIDc PWDc IDs (1) 2) Third-party certification agency gets the user in- formation (including user name, password, etc.) and Table 1. Parameter description of ce rtification. Abbreviation Content AC Third-party certification agency CSP Client’s security service agent SSP Web server’s security service agent Message The encrypted message that third-party certification agency return to the client’s security service agent Key The encryption key that third-party certifi- cation agency uses to encrypt the Message IDc Client ID IDs Web server ID PWDc Client password SOAP(Head, Body)SOAP message COMPARE( ) Certification agency compares requestor’s information with that in the database compares them with that in the database: :, A CCOMPAREIDc PWDc (2) 3) After the comparison, if properly the third-party certification agency will return a message encrypted with the Key, and otherwise it will reject the user’s authentic- cation request. : A CCSPSOAP Message (3) 4) The third-party certification agency sends the Key used to e ncrypt th e Message to the Web server: : A CSSPSOAPKey (4) T. XU ET AL. Copyright © 2011 SciRes. JIS 4 3.3. Web Server’s User Authentication of SIMSA Model When the client’s security service agent receives the en- crypted Message that the third-party certification agency returns, the client can use the Message to invoke the Web service in the server. The SOAP message that client's security service agent sends to the Web server’s security service agent includes the client ID and Message, and its formal description is: :,,CSPSSPSOAPHeadIDcMessageBody (5) When the SOAP message including the client ID and the Message reaches the Web server’s security service agent, the security service agent must verify the SOAP message whether the client has the permission to call the Web service. In the process it will verify whether the ID included in the Message is the same as the client claims, if they are the same client could invoke the Web service. A user authentication policy is designed in the server’s security service agent for the authentication of the client ID. The user authentication policy is shown in Figure 2. The process of Web server’s user authentication is: 1) Extract the Key used to encrypt Message from the SOAP message that third-party certification agency sends. 2) Extract the client ID and Message from the SOAP message that client sends. 3) Use the Key to decrypt the Message and extract the client ID that the Message contains. Figure 2. User Authentication Policy. 4) Verify whether the ID that client claims is the same as that in the Message, if they are the same, the client will be allowed to call the Web service, otherwise au- thentication will fail. 3.4. Security Service Agent of SIMSA Model After the user’s request passes through the identity vali- dation in the Web server, a connection is established be- tween the Web server and client, and customers can call the Web service. In order to ensure the security of Web services exchanged between heterogeneous platforms, the SOAP messages transmitted between the server and cli- ent must be handled safely. The security service agent module of SIMSA implements these security require- ments, and it achieves security interaction of end to end in message-level mainly through the security extension of SOAP message. This module is to realize the signa- ture and encryption of SOAP message. Figure 3 shows the security service agent module of SIMSA. To formally descript the security interaction process of SOAP messages between heterogeneous platforms, Ta- ble 2 defines the relevant parameters and their functions. The simplest form of security interaction of SOAP message is that a signed and encrypted Web service re- quest M1 is sent to the server security service agent from the client security service agent and corresponding to that the server security service agent will return a re- sponse message M2 which has been handled safely to the client security service agent. The security interaction pro- Table 2. Parameter description of security interaction in heterogeneous platform. Abbreviation Content S,C Web server and client built on different platforms Cc Client certificate Cs Server certificate Pu(cert) Public key of cert Pr(cert) Private key o f cert Mes SOAP Message S(Pr(cert), Mes) Use the private key of cert to sign the Mes Dm The digital signature of Mes VS(Mes, Pu(cert), Dm)Use the public key of cert to validate the digital signature of Mes E(Pu(cert), Mes) Use the public key of cert to encrypt the Mes DE(Pr(cert), Mes) Use the private key of cert to decrypt the Mes T. XU ET AL. Copyright © 2011 SciRes. JIS 5 Figure 3. Security Service Agent Module. cess of SOAP message can be formally described as: 1) Client request: encrypt and sign the request message. 11 :,,Pr,CSEPuCsMSCcM (6) 2) Server: verify the signature and decrypt the request message. 11 1 :, ,,Pr,SVSM PuCcDmDECsM (7) 3) Server response: encrypt and sign the response mes- sage. 22 :,,Pr,SCEPuCcMS CsM (8) 4) Client: verify the signature and decrypt the response message. 22 2 :, ,,Pr,CVSMPu CsDmDECcM (9) 4. Security Interactive Example The user authentication module and security service agent module of the SIMSA are realized in this paper. They implement the user authentication in heterogeneous platforms and security extension of SOAP message dur- ing the process of Web service interaction. 4.1. User Authentication Implementation The client sends the request SOAP message to the third- party certification agency. The message’s format is shown in Figure 4, in which <authentication> shows the infor- mation required certification agency to verify; <clien- tID> specifies the client ID; <password> specifies client password and <serverID> specifies server ID. The third-party certification agency queries the data- base to verify the client request SOAP message and after that it returns an encrypted SOAP message including the client ID and the encrypted Message to the client. The message’s format is shown in Figure 5, in which <Mes- sage> contains the encrypted information. The third-party certification agency sends the encrypt- tion key which is used to encrypt the Message to the Web server. The encryption key can be used to decrypt the Message in the user authentication security strategy when the client calls the Web service. The SOAP mes- sage’s format is shown in Figure 6. <soapenv:Header xmlns:wsa="http://www.w3.org/2005/ 08addressing"> <authentication> <clientID>admin</clientID> <password>admin123</password> <serverID>server</serverID> </ authentication> </soa p env:Hea de r > Figure 4. Client Request SOAP M essage. <soapenv:Header xmlns:wsa="http://www.w3.org/2005/ 08addressing"> <ToClient> <clientID>admin</clientID> <Message>encrypted message…</Message> </ ToClient> </soapenv:Header> Figure 5. SOAP message that certification agency returned to the client. <soapenv:Header xmlns:wsa="http://www.w3.org/2005/ 08addressing"> <ToServer> <key>Key</key> </ ToServer> </soapenv:Header> Figure 6. SOAP message that certification agency returned to the server. T. XU ET AL. Copyright © 2011 SciRes. JIS 6 <?xml version='1.0 ' encoding='utf-8'?> <soapenv:Envelopexmlns:soapenv="http://www.w3.org/2003/ 05/soap-envelope"> <soaenv:Header xmlns:wsa="http://www.w3.org/2005/ 08/addressing"> <wsse:Security xmlns:wsse="http://docs.oasis-open.org /wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd " soapenv:mustUnderst and="true"> <ds:Signature> <ds:SignedInfo> <ds:CanonicalizationMethod Algorithm="http:// www.w3.org/2001/10/xml-exc-c14n#" /> <ds:SignatureMethod Algorithm="http://www.w3.org /2000 / 0 9/x m l dsig#r sa - sha1" /> <ds:Reference UR I="#id-8303462"> <ds:Transforms> <ds:Transform Algorithm="http://www.w3.org /2001/10/ xm l-exc-c14n#" /> </ds:Transforms> <ds:DigestMethod Algorithm="http://www.w3.org /2000 / 0 9/x m l dsig#sha1" /> <ds:DigestValue>q0ut1qK9WER7MXSuX 4vV4wYS3oQ=</ds:DigestValue> </ds:Reference> </ds:SignedInfo> <ds:SignatureValue> SKPKP5ICsX/lcZzCdYxk0cAsQV6Gbyau0bBJvpq NKL/kSyh9KvUMJIJ7i96gT46tCdexHne+LzE2CO 1xUkBLDv8+zX049Klk++BdqiuZLF6PB/X79dqyd RlWYOMYuN2nMvP5Qdo3MzYOvvi2K7w3gcbiy euDwmWglkeR8iCqHvk= </ds:SignatureValue> <ds:KeyInfo Id="KeyId-11463270"> <wsse:SecurityTokenReference xmlns:wsu="http:// docs.oasis-open.org/wss/2004/01/oasis-200401-wss- wssecurity-utility-1.0.xsd" wsu:Id="STRId-367156"> <ds:X509Data> <ds:X509IssuerSerial> <ds:X509IssuerName>CN=Sample Client,OU= Rampart,O=Apache,L=Colombo,ST=Western, C=LK</ds:X509IssuerName> <ds:X509SerialNumber>1187603652 </ds:X509SerialNumber> </ds:X509IssuerSerial> </ds:X509Data> </wsse:SecurityTokenReference> </ds:KeyInfo> </ds:Signature> </wsse:Security> <wsa:To>http://10.6.233.177:8080/axis2/services/Signiture. signitureHttpSoap12Endpoint/</wsa:To> <wsa:MessageID>urn:uuid:22EC2A05BDC41A98491289 284864538</wsa:MessageID> <wsa:Action>urn:echo</wsa:Action> </soapenv:Header> <soapenv:Body> <xenc:EncryptedData> ...... </xenc:EncryptedData> </soapenv:Body> </soapenv:Envelope> Figure 7. Security SOAP Message. 4.2. SOAP Message Signed and Encrypted by Security Service Agent The SOAP message output from the server security ser- vice agent is signed and encrypted. The signed part of the message is shown in Figure 7. <ds:Signature> mainly consists of three parts: <ds:SignedInfo>, <ds:Signature Value> and <ds:KeyInfo>. <ds:SignedInfo> also contains three parts including <ds:SignatureMethod>, <ds:Digest Method> and <ds:DigestValue>. <ds:SignatureMethod> indicates the algorithm that signature used; <ds:Digest Method> indicates the algorithm need to be used to ge- nerate the abstract data; <ds:DigestValue> specifies the abstract data. <ds: SignatureValue > points out the sig- nature value. <ds:KeyInfo> shows the information of the certificate which signature uses, including the data of the X.509 certificate and the information of the certificate p u- blisher. <soapenv:Body> contains only one element named <xenc:EncryptedData> which indicates the en- crypted information. As the encrypted information is too large, the part of the information is omitted. From Figure 7 it can be seen that the SOAP message has been successfully signed and encrypted which en- sures the security of SOAP messages transmitted be- tween different platforms. 5. Conclusions SOA promotes the application and integration of infor- mation technology, but the security of application and integration is much more complex. In connection with SOA application and integration practice, the security issues of Web service in the SOA architecture have been proposed. In order to solve these issues, a security inter- active model of heterogeneous platform named SIMSA is designed. This model realizes security requirements during the process of calling Web services in heteroge- neous platform. By making client authentication, signing and encrypting SOAP message in the process of Web service interaction in heterogeneous platform, it achieves the security interaction of Web service in heterogeneous platform, which greatly enhances Web service’s security features. 6. References [1] F. Satoh, et al., “Adding Authentication to Model Driven Security,” IEEE International Conference on Web Ser- vices (ICWS), Chicago, 2006, pp. 585-594. doi:10.1109/ ICWS.2006.25 [2] K. Bhargavan, C. Fournet, et al., “An Advisor for Web Services Security Policies,” Proceedings of the 2005 workshop on Secure web services, New York, 2005, pp. 1-9. doi:10.1145/1103022.1103024 [3] S. Weber, P. Austel and M. McIntosh, “A Framework for Multi-Platform SOA Security Analyses,” IEEE Interna- tional Conference on Web Service, Salt Lake City, 2007, pp. 102-109. [4] J. Viega, “Why Applying Standards to Web Services is T. XU ET AL. Copyright © 2011 SciRes. JIS 7 not Enough,” IEEE Security and Privacy, Vol. 4, No. 4, 2006, pp. 25-31. doi:10.1109/MSP.2006.110 [5] Z. P. Liu, D. D. Zhou, L. Y. Xue, X. M. Chang and X. J. Song, “A Security Model of Web Service Based on SOAP,” Journal of Wuhan University in Chinese, Vol. 52, No. 5, 2006, pp. 570-573. [6] L. Y. Tang and S. H. Qing, “Administration of Multiple Roles in the Hybrid RBAC-DTE Policy,” Chinese Jour- nal of Computers, in Chinese, Vol. 29, No. 8, 2006, pp. 1419-1425. [7] X. M. Wang and Z. T Zhao, “Role-Based Access Control Model of Temporal Object,” Acta Electronica Sinica, in Chinese, Vol. 33, No. 9, 2005, pp. 1634-1638. [8] W. F. Zheng, T. Xu and Q. F Gu, “Design and Imple- mentation of Core Service in Civil Aviation Integrated Information Platform,” Computer Engineering, In Chi- nese, Vol. 34, No. 21, 2008, pp. 267-269. [9] R. Bunge, S. Chung, B. Endicott-Popovsky and D. McLane, “An Operational Framework for Service Ori- ented Architecture Network Security,” Proceedings of the 41st Hawaii International Conference on System Sciences, Waikoloa, 2008, pp. 312-320. [10] N. Bieberstein, S. Bose, M. Fiammante, K. Jones, R. Shah and Z. Ning, “Service-Oriented Architecture Gu- ide,” in Chinese, Posts & Telecom Press, Beijing, 2008, pp. 160-166. [11] Z. P. Liu, X. M. Chang, D. D. Zhou and X. J. Song, “A Safe ID Authentication Policy in Web Service,” Journal of Computer Research and Development, in Chinese, Vol. 43, 2006, pp. 551-555. |