SOAP-Based Security Interaction of Web Service in Heterogeneous Platforms *

With the development and application of SOA technology, security issues of Web services based on heterogeneous platform have become increasingly prominent. The security of SOAP message is of great importance 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.


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 services installed in different locations have different access rights and security policy (encryption, signature, prevention of attacks, etc.).How to guarantee the security of services has become hot spot in foreign research institutions and scholars.IBM Tokyo Research Institute (Fumiko Satoh et al.) puts forward the best practice models and support tools for the specific service safety profile construction for the IBM Websphere Server according to security policy using mapping rules [1].Microsoft Research in University of Cambridge (Karthikeyan Bhargavan et al.) [2] publishes a security policy configuration guidance to help developers construct the security policies 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 heterogeneous 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 achieve 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 authorization.As for how to use them to achieve the goal of SOA security, it presents a challenge both in theoretical and technical practices [4,5].
Authentication policies and SOAP message-based security interactive study of Web services in heterogeneous platforms have been proposed in this paper.First the security feature of heterogeneous platforms is analyzed, and then the details of the security interaction model of heterogeneous platform named SIMSA is given.Combined with concrete application examples, user authenticcation during a Web service call as well as the safe handling of SOAP messages in heterogeneous platforms is achieved.The security model provides theoretical support for the security interacts of Web services in heterogeneous platforms and is verified by experiments.This model ensures the security interactions of Web service effectively.
vices.In the development of Web service's logic functionality, if the security features are designed, Web services will become extremely complex and service performance and scalability will be greatly reduced.In terms of the analysis on the security needs and consideration 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 services, but also can achieve the security of SOAP messaging [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 Microsoft'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 mechanisms 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 security policy and platform technology.Then it needs an agent mechanism dealing with service security to package the specific realization of platform security from the logic, so that the security SOAP information of heterogeneous platform can be consistently understood and treatment.
Security processing mechanisms of Web services in heterogeneous platform provide security policy configuration and security implementation method of SOAP message [4].Security service agents use WS-Security and other specifications to achieve the following three aspects of security requirements of SOAP message [10,11]:  Message integrity WS-Security takes XML signature to do digital signature for SOAP message to ensure that SOAP message passes through intermediate nodes without being tampered.
 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 tokens, which can represent the identity of the message sender.Combined with digital signatures, the message recipient can confirm the legitimacy and authenticity of the SOAP message sender.

Security Model for Heterogeneous Web
Services SIMSA Security framework and configuration strategies for heterogeneous platforms are quite different.Therefore, in order to achieve the security interaction of Web service in heterogeneous platforms, a third-party certification agency must be added.It can complete the relevant certification 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 encryption of the SOAP message.The authentication module 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 heterogeneous 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.

 UDDI Server
Its main function is to store service descriptions by category.It can be a private registry, such as Capeconnect'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 corresponding WSDL document. Security Service Agent It is the core module of the model.It is responsible for

Third-Party Certification Agency of SIMSA Model
In order to provide reliable authentication information for the Web server, SIMSA adds a third-party certification agency.Certification agency will compare the requestor'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 encrypted 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 defines the parameters and function description.The formal description of certification process in thirdparty certification agency is shown as follows (the following numbers correspond to that in SIMSA): 1) Client's security service agent sends user information to the third-party certification agency: 2) Third-party certification agency gets the user information (including user name, password, etc.) and 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 authenticcation request.

 
4) The third-party certification agency sends the Key used to encrypt the Message to the Web server:

Web Server's User Authentication of SIMSA Model
When the client's security service agent receives the encrypted 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: 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.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 authentication will fail.

Security Service Agent of SIMSA Model
After the user's request passes through the identity validation in the Web server, a connection is established between 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 client must be handled safely.The security service agent module of SIMSA implements these security requirements, 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 signature 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 request 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 response message M2 which has been handled safely to the client security service agent.The security interaction pro-   cess of SOAP message can be formally described as: 1) Client request: encrypt and sign the request message.
2) Server: verify the signature and decrypt the request message.
3) Server response: encrypt and sign the response message.

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 during the process of Web service interaction.

User Authentication Implementation
The client sends the request SOAP message to the thirdparty certification agency.The message's format is shown in Figure 4, in which <authentication> shows the information 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 database 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 encrypttion 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 message's format is shown in Figure 6.

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 generate the abstract data; <ds:DigestValue> specifies the abstract data.<ds: SignatureValue > points out the signature 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 publisher.<soapenv:Body> contains only one element named <xenc:EncryptedData> which indicates the encrypted 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 ensures the security of SOAP messages transmitted between different platforms.

Conclusions
SOA promotes the application and integration of information 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 interactive model of heterogeneous platform named SIMSA is designed.This model realizes security requirements during the process of calling Web services in heterogeneous 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.

Figure 1 .
Figure 1.SIMSA Model. the security of Web service during transmission and achieves 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 responseble for the request verification of client's identity, and only authenticated users can call the appropriate Web service.
(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