The road to the architect 13th day Axis2 Web Service Security Preliminary

A brief introduction of Wssecurity

A secure Web service is a necessary guarantee of the success of a Web service. But as you know, Web services use XML for data exchange, and XML is plaintext encoded by default, while most Web services use the HTTP protocol as a transport protocol, and HTTP is also used to transmit data in plaintext. This results in the transmission of unencrypted information on unencrypted transport protocols, which threatens the confidentiality of information transmissions. As an enterprise-class application, the above approach does not meet the basic security requirements:

2 when data is transmitted over the Internet, it should not be visible to third parties;

2 The two sides must be able to examine each other's sources;

2 Both parties must be able to determine that the transmitted data has not been modified by hackers in the middle.

By using the SSL protocol, we can solve the first problem: "Should not be seen by a third party"; using digital signatures and digital certificates can solve the two subsequent problems. When using the digital certificate method, the WEB service requester must have a digital certificate signed by a trusted authentication center. The requestor uses this certificate to indicate their identity and to digitally sign the SOAP message. When a message is received by the other system, the message can be time-stamped and logged. At this point, the digital signature is validated. The validation process ensures that the message is from the sender and also verifies that the message content has not been tampered with during transmission.

IBM, Microsoft, and Verisign jointly published a specification for Web service security (Web Services security,ws-security) in December 2002 that describes how to attach a signature and cryptographic header to a SOAP message In addition, it describes how to attach a security token to a message, including a binary security token, such as a X.509 certificate, and provides a mechanism to help WEB service developers protect SOAP message exchanges.

Depending on the level of security requirements applied, there are different ways to implement security, and here are some of the most common implementations (ranging from low to high):

2 Java EE Web application default access control (data is plaintext);

2 access control using axis handler (the data is plaintext);

2 Use the servlet filter (filter) for access control (the data is plaintext);

2 using the SSL/HTTPS protocol to transmit (encrypted data transmission protocol);

2 uses the Ws-security specification to encrypt and authenticate the information (data is encrypted transmission).

The first three approaches are feasible for applications with low security levels, which enable access to resources by using the Web application access authentication mechanism for authorization. However, it should be noted that, although they have been authenticated, but the transmission of information is still in the form of plaintext, can not guarantee that information in the transmission process is not stolen. SSL is a secure transport protocol that uses it to transmit Web services to ensure that information is not stolen by third parties. But it has one drawback is that it consumes a lot of system resources. The last way, the information is signed and then encrypted, and then the encrypted information network spread, so that even if the third party to obtain encrypted transmission information, can not decrypt. For systems with high security level requirements, the Ws-security specification should be used as a Web services security solution.

WS based on HTTPS communication and authenticated with user name password

In general applications, we can use HTTPS to protect the plaintext data we transmit.

The key is that we need to verify the client's request, which requires a basic username and password to access my web Service, which we call basic Auth.

2.1 Error procedure

In many projects, some development teams in order to map the trouble, the customer's control of the environment is not good, in order to verify a webservice, we often use the following verification methods:

First type:

Http://xxxx.xxx.xxx/abc.wsdl?username= Verification Head &password= verification head

Server to get this URL to the Username,password used Request.getparameter out, and the database a match, verify.

The second type:

<request xmlns= "http://10.225.106.35" >

<username> Verification Head </username>

<password> don't always be your head and your head </password>

<BusinessData>2007-01-01</BusinessData>

</Response >

After the service is received, the SOAP request body's <username> and <password> are taken out and the database is matched and validated!

These two practices, is undoubtedly the!!! ( don't talk to me about business implementation is the most important, and so your data is not the day, the director manager's wages have been tampered with, if you are willing to be customers to make the east, then you can do it. )