Use WSE to verify user identity in Web Services (1)

I. Web ServicesSecurityAnd WS-Security

There is no doubt that soap and XML Web Services have completely changed the pattern of e-commerce in terms of interaction operations and standards.

However, until recentlyTechnologyThere are still some defects in the field: Message-level security, authentication, encryption, digital signature,RoutingAnd attachmentsProblemCapabilities. ToSolutionCompanies and organizations such as IBM, Microsoft, and VeriSign are taking the lead in developing unified web service security specifications to leverage their original web service interactive operation concepts and business models, they introduced WS-Security and other specifications. It can be said that since the formation of the SOAP specification, the WS-Security Specification and its subsequent work may be one of the most important advances in the Web Service technology field.

With the finalization of WS-Security specifications, major software vendors began to seriously consider providingUseWith the same interface and programming toolbox of Web Service Security Language, Web Service developers will also be able to use the tools provided by these vendors to enhance the security of their developed web services.

Ii. WSe security performance Overview

Microsoft launched Web Services enhancements 1.0. net (WSE) is a class library used to implement advanced Web service protocols. This is also the company's first tool suite to implement SOAP message security using WS-Security and other specifications.

An important part of protecting the security of web services is to protect the security of SOAP message transmission.

After WSE is used, soap messages can verify their integrity by themselves and can be encrypted using mechanisms defined in the WS-Security Specification.

All WS-Security features supported by wse1.0 are implemented through the security Input and Output filters of securityinputfilter and securityoutputfilter objects. They support the following security features:

1. Digital Signature

2. Encryption

3. Sign and encrypt with the user name token

4. Use X.509 Certificate Signature and Encryption

5. Use a custom binary token for signature and Encryption

Wse1.0 does not support Security Assertion Markup Language (SAML), but Microsoft is actively implementing the SAML architecture in its. NET Server. Of course, developers can freely implement SAML. The only drawback is that the WS-Security interface of the web service that follows the WS-Security Specification cannot be used.

The WSE architecture model is based on the filter pipeline that processes inbound and outbound soap messages. It is based on the existing soapextension class. developers who have used the soapextension class traveling compression, encryption, record and other operations will find that they are very familiar with WSE.

WSe provides a Microsoft. web. services. the soapcontext class allows us to process WS-Security SOAP Headers and other inbound SOAP Headers, and add WS-Security headers for outbound soap messages. WSe also has a packaging class to add soapcontext for SOAP requests and responses (similar to httpcontext ).ServerUse a soapextension class "Microsoft. web. services. webservicesextension "allows us to verify the SOAP message of the inbound, and also provides the request and response soapcontext that we can access from our webmethod.

The biggest obstacle to learning to use WSE is that it is sometimes difficult to understand Microsoft's technical documentation and related articles, even for senior developers with rich experience, there are few articles about this. In this article, I will give a simple example to introduce how to use WSE to verify the basic user name token to ensure the security of web services.

3. Set the WSE Environment

To set up the basic WSE environment, we need to configure the ASP. NET application so that it can use WSE soapextension. SimplestMethodAdd the/configuration/system. Web/WebServices/soapextensiontypes/Add element to Web. config in your web service virtual directory, as shown below:

＜webServices＞＜soapExtensionTypes＞＜add type="Microsoft.Web.Services.WebServicesExtension, Microsoft.Web.Services, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" priority="1" group="0" /＞＜/soapExtensionTypes＞＜/webServices＞

Note that the type attribute must be written in one row, but the length of the attribute must be divided into several lines. Therefore, please pay more attention to it. Note that before using WSE, we must add a reference to Microsoft. Web. Services. DLL to the project.

<! -- Plaintext password --> <userNameToken> <username> user1 </username> <password type = "wsse: passwordtext"> suangywang </password> </userNameToken>

This method uses the plaintext password. It is hard to imagine that a database will be checked on the server, the user name and password will be verified, and whether there is a matching user name/password for this series of verification operations.

<! -- Password abstract --> <userNameToken> <username> user1 </username> <password type = "wsse: passworddigest"> qsmako67 + vzynu9tcmsqofxy14u = </password> </userNameToken>

This method sends a password Digest (Digest) instead of the plaintext password. If you use the password digest, the password will not passNetworkSo that hackers are unlikely to calculate the Web Service password. The password digest is calculated using hash functions. This process is only one-way, meaning that it is impossible to reverse the function and find the message corresponding to the abstract, because this process is implemented in this way, therefore, it is difficult to calculate the two passwords that are hashed to the same abstract. However, hackers can send hash passwords and then impersonate the original sender for verification. To avoid this problem, Web Services Security addendum (Web Service Security Addendum) has added an auxiliary protection measure. The addendum specifies that the digest version of the password must be sent, not just the hash password. The summary contains a password hash that identifies the unique nonce and creation time of the request. Therefore, two identical passwords are not hashed. The modified username token userNameToken is shown as follows.

<! -- Modified username token --> <wsse: userNameToken xmlns: wsu = "http://schemas.xmlsoap.org/ws/2002/07/utility" wsu: Id = "SecurityToken-59845323-5dcb-4a6b-a7fb-94a0d7357a20"> <wsse: username> user1 </wsse: username> <wsse: password type = "wsse: passworddigest"> gpbdxjx79eutcxdtlulilcrssi = </wsse: Password> <wsse: nonce> Signature = </wsse: nonce> <wsu: created> 2003-6-20t21: 16: 50z </wsu: created> </wsse: userNameToken>

Although each legal request has a different hash, you must also prevent malicious users from dropping the entire userNameToken in the legitimate request of other users into their own illegal requests. You can use timestamp (timestamp header) to minimize this risk. The timestamp header indicates the message creation time and expiration time, indicating the message cycle and when the message can be considered invalid. For example, you may want to specify that the message will expire after 40 seconds, and the server will not receive the userNameToken after 40 seconds. However, clock synchronization between machines may result in the rejection of valid requests. Therefore, using timestamps is not a perfect solution. To solve this problem, the Web service can save a table with the nonce value of the recently received userNameToken. If the nonce value of the received request has been used, this request will never be accepted. If you receive several requests that use the same nonce, you should consider dropping all these requests, because it is very likely that the first request is illegal. We also need to learn that the nonce check technology does not prevent malicious users from intercepting valid input information, and add userNameToken in the original information to our own message and then send it to the destination. In this case, you need to add a digital signature or security certificate to the message to protect it from attacks. Knowledge about digital signatures and security certificates is not covered in this article. Please refer to the relevant documents.

All hash protection requires the message sender and receiver to know the user's password. On the client, people expect the system to prompt the user to enter the password. On the server side, you need to save a table with a valid user name/password pair for the system to search. The following describes how WSE uses a password provider mechanism to solve these two problems.