Use Web Services security mechanisms to Encrypt SOAP messages

Author: Zhao xueshan, source: developerworks China, responsible editor: ye Jiang
This article describes how to use the soap of Websphere information integrator content Edition
The message mechanism is improved to provide message integrity and confidentiality. This article also explains how to integrate the existing security mechanisms of Websphere Iice into Web Services.
Security Implementation. At the same time, this article is also a very good practice for implementing the web services security mechanism.

This article describes how to use WebSphere information integrator content
Edition SOAP message mechanism is improved to provide message integrity and confidentiality. This article also explains how to use WebSphere Iice
The existing security mechanisms are integrated into web services security implementation. At the same time, this article is also a very good practice for implementing the web services security mechanism.

Security has been recognized as one of the key factors for the success of the e-commerce market, especially for web services applications in distributed systems. WebSphere
Information integrator content edition (hereinafter referred to as WebSphere
As a leader in the enterprise information integration field, Iice provides several soap-based services.

This article describes how to improve the WebSphere Iice SOAP message mechanism to provide message integrity and confidentiality. This mechanism includes the use of XML
The digital signature is used to sign the message to achieve message integrity, and the XML encryption is used to encrypt/decrypt the message to achieve message confidentiality. This article also explains how
Iice's existing security mechanisms are integrated into web services security implementation. At the same time, this article also implements the Web
A very good practice of services security mechanism. It not only facilitates the arbitrary extension of security models and algorithms, but also the implementation principles in this article can be easily transplanted to all IBM needs to achieve
Web services security products.

　　1. Background and motivation

As a leader in enterprise information integration, WebSphere Iice implements a web
Services. It provides three types of soap services and names them WebSphere Iice Web Services. These services-Web
Services interface, soap client proxy, and soap ctor proxy-enables WebSphere
Iice can be easily deployed on the Internet and accessed by other services on the Internet. WebSphere
These features of Iice not only enable Asynchronous interaction between distributed components, but also enable WebSphere
The Distributed Components of Iice can interact with each other in a stateless manner, thus omitting session state management. At the same time, you do not have to consider implementing service protocols and service locations.

Unfortunately, this loose and open protocol environment is vulnerable to potential security threats. A Web Services message must be transmitted in many intermediate media before it reaches its destination. Therefore, a mature message-level security mechanism becomes extremely important.

Currently, WebSphere Iice provides technical solutions to solve the transmission security problem of soap messages in the real e-commerce network environment. For example, the security algorithm is simple and the encryption structure is flexible.

The SOAP specification makes it easy for any security mechanism (digital signature, information integrity protection, encryption/decryption, etc.) to be applied to any Web Services-based application.

IBM has provided a complete technical policy-WS-Security. In this way, the entire industry can implement this standard-based structure to meet the complex and flexible needs of real business.
Web services security requirements. Enhance the Web
With the scalability of the Service core module, we can obtain solutions based on core technologies such as SOAP, WSDL, XML Digital Signature, XML encryption/decryption, and SSL/TLS.
This allows web services providers and demanders to develop solutions based on their application security needs. These solutions and standards enable us to easily
The services security solution is integrated with WebSphere Iice web services components.

　　2. Implementation Principle

　　2.1 WebSphere Iice web servives Overview

Currently, WebSphere Iice provides two levels of web services components: Soap client proxy and soap
Connector proxy and Web Services API. We call this part WebSphere Iice Web
Services Client: another part is as WebSphere Iice
The server-side SOAP implementation released by the web module. This web module uses the Iice interface as the Web
Services is released and these interfaces are integrated with other modules. From a technical point of view, WebSphere Iice Web
Services components use the Apache axis toolkit. We can simply put WebSphere
Iice is understood as the axis client and the axis server. The following describes the details of Websphere Iice web services components.

The soap client proxy layer (Part 1) uses soap as the standard API of Websphere Iice and the interaction protocol of accessservices components.

The soap connector proxy layer (Part 1) uses soap as the interaction protocol between the accessservice EJB component and the deployed EJB ctor EJB component. This implementation mechanism is very similar to the implementation mechanism of the soap client proxy layer.

Figure 1: WebSphere Iice web services components

Web services call interface (part 1 3) provides a vast majority of the content of the WebSphere Iice integrated interface through the soap interface. It includes a WSDL file that defines the Calling Interface and provides a language-independent way to access unstructured data on the Internet.

2.2 principle of Websphere Iice ciphertext Login

WebSphere Iice encryption is an implementation of the blowfish algorithm. Once the installation is successful, WebSphere
Iice will use this algorithm to generate a key file and ensure that the file is in the classpath of the client and connector. Use blowfish for encryption/decryption.
.

List 1: use blowfish for encryption and decryption

Client encryption process: // Create and encrypt an authbundle. Authbundle AB = new authbundle (user, password ); Try { // Encrypt the auth bundle (New blowfishsealer (). Seal (AB ); } Catch (keynotfoundexception knfe ){ ... } Server-side decryption process: ... Use the sealed bundle to logon to a chosen repository. .. // Unseal the auth bundle if sealed. If (authbundle. issealed ()){ // Instantiate an unsealer proxy. Unsealerproxy up = new unsealerproxy (); Try { // Attempt to unseal the bundle. // The unsealerproxy will delegate unsealing // To a new instance of "My. Magic. unsealer" Up. Unseal (authbundle ); } Catch (unsealernotfoundexception unfe ){ Throw new logonexception ("Unable... Unsealer. ", unfe ); } Catch (keynotfoundexception knfe ){ Throw new logonexception ("unable .... ", Knfe ); } Catch (invalidkeyclassexception ikce ){ Throw new logonexception ("invalid decryption...", ikce ); } Catch (encryptionexception ee ){ Throw new logonexception ("an error .... ", Ee ); } } ...

　　2.3 WebSphere Iice Web Services SOAP message Security Overview

Because WebSphere
Iice uses axis as the SOAP engine. First, we need to understand the axis mechanism. It can be said that the task of axis is to process messages. When the core processing logic of axis is started
The series handles are called sequentially. The Calling sequence is determined by two factors: Deployment file and whether the engine is a client or a server.

WebSphere Iice Web
Services is processed by a series of client-side and server-side axis/JAX-RPC handles. To make this security solution work properly, these handles must be installed and must be properly installed
The order is correct. This document provides two handles for message encryption/decryption and message integrity verification. At the same time, ensure that these four handles are correctly installed in the WSDD configuration file on the client and server,
In this way, each message sent from the client is encrypted and signed by the client certificate, and each message received by the server is verified and understood
Password. In this way, the integrity and confidentiality of soap messages are realized.

You can also choose whether to use this security mechanism. If the user prefers a non-security mechanism, all he needs to do is to comment out the WSDD configuration file on the client and server.

2.4 WebSphere Iice Web Service SOAP message Security Implementation Details

A. Configuration

The configuration of Websphere Iice web services security mechanism is composed of two parts: client and server. As described in the following configuration file instance, a SOAP message is signed and encrypted by different handles before it is sent to the target server. Correspondingly, it will also be verified and decrypted on the server side.

List 2: Axis client configuration file example

<Globalconfiguration> <Requestflow> <Handler Type = "Java: COM. venetica. VBR. WebServices. handler. x509signhandler"/> <Handler Type = "Java: COM. venetica. VBR. WebServices. handler. encrypthandler"/> </Requestflow> <Responseflow> <Handler Type = "Java: COM. venetica. VBR. WebServices. handler. x509signhandler"/> <Handler Type = "Java: COM. venetica. VBR. WebServices. handler. decrypthandler"/> </Responseflow> </Globalconfiguration>

The server configuration file is very similar to the client configuration file.

B. Signature and encryption/Decryption processes:

The SOAP message signature and encryption/decryption process 2 is shown below:

Figure 2: SOAP message signature and encryption/decryption process

List 3: XML Signature sample code

Public message signsoapenvelope (soapenvelope unsignedenvelope) throws exception {// Wssignenvelope signs a SOAP envelope according to // Ws specification (X509 profile) and adds the signature data // To the envelope. Wssignenvelope signer = new wssignenvelope (); String alias = "username "; String Password = "password "; Signer. setuserinfo (alias, password ); Document Doc = unsignedenvelope. getasdocument (); Document signeddoc = signer. Build (Doc, crypto ); // Convert the signed document into a SOAP message. Message signedsoapmsg = (Org. Apache. axis. Message) axisutil. tosoapmessage (signeddoc ); Return signedsoapmsg; }

List 3 shows the XML signature process: first obtain the SOAP envelope, then obtain the user certificate information, generate the signature object, and then use this signature object to sign the envelope, finally, a new SOAP message is generated from the signed envelope.

List 4: XML encryption sample code

Public message encryptsoapenvelope (
Soapenvelope unsignedenvelope, message axismessage)
Throws exception
{
Wsencryptbody encrypt = new wsencryptbody ();
// Build the encrypted soap part
Document Doc = unsignedenvelope. getasdocument ();
Document encrypteddoc = encrypt. Build (Doc, crypto );
// Convert the document into a SOAP message
Message encryptedmsg =
(Message) axisutil. tosoapmessage (encrypteddoc );
// Retrieve the desired soap part
String soappart = encryptedmsg. getsoappartasstring ();
(Soappart) axismessage. getsoappart (). setcurrentmessage (soappart, soappart. form_string );
Encrypteddoc = axismessage. getsoapenvelope (). getasdocument ();
// Convert the document into a SOAP message
Message encryptedsoapmsg = message) axisutil. tosoapmessage (encrypteddoc );
Return encryptedsoapmsg;
}

List 4 shows the encryption process: first obtain the SOAP envelope before encryption, then obtain the user's certificate information and generate the encryption object, then, the encrypted object is used to encrypt the obtained SOAP envelope, and a new SOAP message is generated based on the encrypted SOAP message and then passed down.

C. Message comparison:

Figure 3 and figure 4 show the comparison between signed messages and encrypted messages.

Figure 3: Comparison of soap messages before and after Digital Signatures

Figure 4: Comparison of soap messages before and after application security encryption

　　3. Benefits

• This practice not only effectively improves the security of Websphere Iice Web Services soap messages, but also meets new requirements of great significance for users.
• B. This practice provides an example to implement the latest and popular Web Services security standards and apply them to IBM products.
• C This practice provides examples of how to integrate newer technologies with existing IBM solutions to meet users' new needs.
• D. This practice shows how to apply web services security to IBM products using Web Services technology.
• E WebSphere Iice security implementation mechanism has good scalability.

　　4. Conclusion

This practice improves the Web Services SOAP message Security Mechanism of Websphere Iice. An example of applying the latest technical standards to IBM products is provided. This not only satisfies users' new needs, but also extends the application scenarios of IBM products.