Preface
====
In recent work, we need to encrypt and digitally sign the content transmitted by the web service. I use the soap extension to modify the SOAP message method for encryption and decryption, in this way, you do not need to improve the code of the original program to achieve the goal of secure transmission.
Ideas
====
My design idea is: the client program uses the configuration file to notify the encryption and decryption class inherited from soapextension whether messages need to be encrypted, an extended SOAP message header is automatically added to the SOAP message to indicate whether the SOAP message package is encrypted. When the server receives the SOAP message package, it first extracts the extended SOAP message header and determines whether to perform signature verification and decryption Based on the specified encryption status. When the server returns a message, it also determines whether to encrypt and sign the feedback information based on the obtained client encryption and decryption requirements. In this way, each client determines whether to use encryption based on its own security needs. The server will automatically decrypt and determine based on each received message, each client can independently exercise its own security level without affecting other users.
Process
====
In soapextension, The processmessage method is rewritten to process each SOAP message sent and received. The soapmessage parameter that is unique in this method contains a stream-type message stream object, which is the SOAP message package sent and received.
Before each client sends a message (beforeserialize stage), it determines whether to encrypt the message based on the flag specified in the configuration file, and adds a new soapheader extension to the message header list of the current SOAP package, the extended soapheader is used to indicate whether the receiver's soap package is encrypted and digitally signed. In the afterserialize stage, the SOAP message package is encrypted according to instructions. On the server side, in the beforedeserialize stage, obtain the extended soapheader object and decide to decrypt the received SOAP message package according to its instructions.
Solution
====
This solution ignores the fact that the soapheader is in the SOAP message package. If you encrypt the entire SOAP message package, you cannot obtain the soapheader before decrypting the entire SOAP message. However, this does not impede the implementation of the solution.
First, do not encrypt the entire SOAP message package, but only encrypt the body part of the SOAP message package;
In this solution, we cannot keep the soapheader confidential. Therefore, we recommend that you do not use soapheader to store and transmit data from hosts.
Second, encrypt the entire SOAP message package, except that the custom httpheader is used to indicate the encryption status of the currently attached SOAP message package.
The disadvantage of this solution is that it depends on the specific transport layer protocol. Of course, you can also customize a format to put the identifier indicating the encryption status of the message package in the message body. When receiving the message package, resolve the indicator value before performing subsequent operations.
I am using the second solution (that is, using the HTTP header to identify the encryption STATUS OF THE SOAP message package ). This is troublesome in soapextension, because soapextension does not provide an opportunity/method for the extended implementers to process the http session message header. There is a contenttype [String] attribute in soapmessage to get or set the HTTP Content-Type of the SOAP request or soap response (default:Text/XML), Bytes ~ It can be used to indicate the encryption status of the soap message package, although msdn does not recommend changing it. Use LoadRunner to detect soap messages and find that the value is"Text/XML charset = UTF-8;", Change it to"Text/XML charset = UTF-8; iscryptograph = trueThe character encoding error of the entire SOAP message is found, and the content obtained by the receiver is completely garbled. net Framework 1.1 does not have this problem, of course, if it is in. in Net Framework 1.1, we recommend that you use the contentencoding attribute to extend your identity. Unfortunately, this attribute is not provided in 1.0.
Finally. in the architecture of Net Framework 1.0, the configuration files on the client and server are used to indicate whether to encrypt and decrypt the SOAP message package. However, in this way, you must maintain the consistency between the client and the server on the configuration flag.Alas ~
Postscript:In the beforedeserialize stage of the client and server, the canseek attribute of the soapmessage. Stream object is different (the canseek attribute of the server is false). Be careful with this, so I am puzzled!
Related Articles: Security: encryption and digital signature