WSE (Web Services Enhancements) is Microsoft to launch functional enhancements in order to create more powerful and better web services through .NET. The latest version is now WSE2.0 (SP2). This article describes how to use a secure function enhancement part in WSE2.0 to achieve secure Web Services. WSE's security function enhancements is a WS-Security standard. This standard is the WebService its own security protocol, which is set by IBM, BEA, Microsoft, etc., so it can be implemented on .NET and Java systems. I mainly based on WSE documentation and yourself (in fact, more than half of the document painting scoop, huh, huh), please point out. In addition, this is 2.0, which varies greatly compared to WSE1.0, especially in security. There is also a little attention, in fact, there are two ways to achieve security through WSE: one is what we need to introduce by writing code; the other is to write a policy file (XML document), these two methods are essentially The security function is achieved by setting the delivery SOAP message, such as increasing user messages, adding decryption, signature verification, etc. But I am not familiar with the second approach, and there is no time study, I don't write, huh, huh.
First, use the username and password to verify the Web Services caller identity. The principle is very simple: the client is extended through the SOAP, and the username and password (clear text or encryption) are added to the SOAP message, send it to the Web Services side; after the server receives the message, the user name and password are obtained from the message context, and then Perform authentication and other operations. The following is an implementation step: Client: 1. Add Microsoft.Web.Services2 and client to access the web services reference, nothing to say. Of course, these two references must be, you may also need to add additional references to the client. 2. Modify the local Proxy class generated from the Web Services reference, this class's code generates the Reference file in the reference. Open the Web Services reference folder you want to operate from the .NET development environment, open the Reference.cs or Reference.vb file. If you don't see these files, you may not display all files, you need to set "display all files" in the Solution Explorer or Command Menu Item. After finding the Reference file, open it, change the inheritance parent class of the class to Microsoft.Web.Services2.WebServicesClientProtocol. Because the Proxy class can access the SOAP extension provided by WSE. Note that if you update a reference to a web service, you need to re-put inheritance class. 3. Add user names and passwords through instances of the UserNameToken class. UserNameToken belongs to Microsoft.Web.Services2.security.Tokens namespace. Suppose the local proxy class name of Web Services is WebServer.WebService, the username is username, the user password is UserPwd, the code can be as shown (VB.NET, the same): 'Generate local proxy class instance Dim Mywebserv AS New Webserver. WebService 'generates an UserNameToken class instance, writes the username, user password, and password mode to the instance Dim UnToken as usernametoken = new usernametoken (username, userpwd, passwordoption.sendPlaintext) Set the SOAP message validity period to determine the message even by other The possibility of reuse after the user intercepted, here is set to 30 seconds, but pay attention to the problem of different system clock synchronization. mywebserv.RequestSoapContext.Security.Timestamp.TtlInSeconds = 30 'will be added to the context instance UsernameToken mywebserv.RequestSoapContext.Security.Tokens.Add (untoken) SOAP Message' method invoke the Web service to be noted here WebMethod mywebserv.WebMethod password transmission mode Set. The password transmission mode is an enumerated data: sendnone, sendhashed, sendPlaintext. Different passwords, sending the password, respectively, and sending the mouth, the above example is to send a plaintext.
If you select SendNone, the server does not verify the password, this security level is very low, and if the service needs to sign the passable SOAP message sign, the client should separately provide a password to its signature; sendhashed means sending a password SHA- 1 Hash value, this situation is safe, which is also the best way to recommend Microsoft. However, it requires the server side to verify the user's identity by writing code and config files, and the specific verification method will tell; sendPlainText is password in a clear text, if this is taken, the UserNameToken in the above code It is best to encrypt, otherwise the password is easily intercepted. The encryption method will be discussed in detail later; Server: 1. First add an element that configures WSE in Web Services, which is also the most basic step for .NET development system using WSE. The WSE document says that this step is required if the service call end is an ASP.NET system. If it is a normal client program, it is not necessary to add this identity. But I tested that I still need to add this configuration even if the call end is a Client program. Here is a complete configuration document.
That is to say, WSE is traversed from the user list of the active directory, looking for a valid user user account that exists and the received username / password, if the matching user is not found, returns an error that the caller is not authorized. It can be seen that the application system and user needs to be tied to the Windows domain, lack flexibility and is not suitable for docking with the existing business system. Therefore, more in practical applications should be used in the following second method. The core of this method is that Web Services is implemented by inheriting the UserNameTokenManager class and overloads the AuthenticateToken method. A. First, declare a class that is inherited from UserNameTokenManager. Public Class CustomuserNameTokenManager Inherits UserNameTokenManager has an access rate, in order to enable authorized assemblies to access this class, you also need to add some access limits when declaring. Because the level of assembly trusts that can access the unmanagedcode is relatively high, you can request access to this class to access unmanagedcode. So the above statement becomes the following form:
Protected Overrides Function AuthenticateToken (ByVal userName As UsernameToken) As String 'Ensure that the SOAP message sender passed a UsernameToken. If userName Is Nothing Then Throw New ArgumentNullException End If' This is a very simple provider. 'In most production systems the following code' typically consults an external database of (userName, hash) 'pairs. For this example, it is the UTF-8' encoding of the user name. Dim encodedUsername As Byte () = _ System.Text.Encoding.UTF8.GetBytes (userName .Username) Return System.Text.Encoding.utf8.getstring (EncodeduserName) End function c. Configure the web.config file to inform Web Services Which class is used to verify the user identity. WSE2 indicated using first added element in the file:
Secondly, use UserNameTokenManager subclass
MessageSignature (unnetken)) MyWebserv.WebMethod The above code is that the client generates a signature according to the instance of UserNameToken, and then adds the signature in the SOAP message, which is the WS-Security extension SOAP message header. Service: In fact, the server does not need to change anything. As long as the SOAP message sent by the client contains a signature, the server automatically verifies the validity of the signature. The server first verifies the username / password, and then uses the client name delivered by the client and the password you obtained (WSE automatically gets the signature from the Windows Active Directory, or by the overloaded AuthenticateToken method). If the verification fails, the description message is changed during the transfer or is not currently called the user, and returns the corresponding error. This piece adds a function that determines if the SOAP contains the signature in the help documentation of the WSE. It is not necessary to get some relevant information of the signature. Interested friends can look at themselves.
Third, using certificate verification identity and use the username / password for the SOAP message signature, there is an intrinsic disadvantage, so we also need to use the certificate to complete the authentication of the user's identity in some security requirements. About the basics of PKI / CA will not be introduced, you can see related information. First we need to configure the server to ensure that WSE can access the certificate and its private key. (As for the application, management and use of the certificate belong to the basics, this is not tailored) This is mainly in the Web Services end setting to ensure that the server can automatically complete some functions, and no user intervention is required. Add the following
Client: The steps of first, 2 are basically the same as the first section using the username / password. But there is also a reference here: Microsoft.Web.Services2.security.x509 3. Write code to get the certificate to use. I used a listView control to display the personal certificate in the current user certificate storage for users to choose. Of course, you can also use the certificate to be used as a certificate of the certificate. The ListView control name is LV_CERTLIST, which has two columns: certificate holder main body and the name of the issuer. Dim cert As X509Certificate Dim lvitem As ListViewItem 'opened from the current user certificate store personal certificate store certstore = X509CertificateStore.CurrentUserStore (X509CertificateStore.MyStore) certstore.Open () lv_certlist.Items.Clear ()' traversing the certificate, written in listview control For Each Cert In CertStore.certificates lvitem = lv_certlist.items.add (cert.getname) lvitem.subitems.add (cert.getissuername) lvitem.tag = lvitem.index next Cert 4. Select the selected certificate to generate an instance of X509SecurityToken, which is the subclass of SecurityToken as the previous UserNameToken. Dim cert As X509Certificate Dim certToken As X509SecurityToken Dim result As String cert = certstore.Certificates (lv_certlist.SelectedIndices (0)) 'determines whether to support the selected certificate signature and the private key if there If cert.SupportsDigitalSignature And Not (cert.Key Is Nothing) Then 'traverse the certificate, written in listview control certToken = New X509SecurityToken (cert) Dim mywebserv As New WebServer.WebService mywebserv.RequestSoapContext.Security.Timestamp.TtlInSeconds = 30' X509SecurityToken mywebserv.RequestSoapContext.Security comprising adding certificate information. Tokens.add (CertToken) 'Use the certificate to sign the SOAP message and write the result in the message mywebserv.requestsoapcontext.security.ements.add (new _ messagesignature (certttoken))' calling the web service method MYWEBSERV.WEBMETHOD END IF
The server: and verify that the message using the username / password sign is similar, the server is also automatically verified the signature validity. At the same time, the server will verify the validity of the certificate based on the attribute settings in the
V. Use the certificate to solve the SOAP message is slightly complex. According to the PKI asymmetric plus decryption principle, the client encrypted on the message needs to be obtained in advance, the certificate public key as the receiver's server, and the server must ensure that the private key corresponding to its certificate can be accessed. So we must first choose to set the certificate it used in the server. The principle is to enable the server to access the private key corresponding to its certificate. For web services developed based on ASP.NET, the default user who needs to be runtably gives an access to the certificate private key. WEB Services default users on IIS 6.0 is Network Service. In other cases, the user account is determined by the username property of the
If you find that the private key file does not exist or inaccessible after the certificate is opened, this certificate has a problem or private key protected, such as password protection or storage in a security peripheral, cannot be automatically accessed by Web Services, so it is not applicable. .
For web services, if the user is used by the default ASPNET, it is best to choose the certificate in the local storage (LocalMachine Store). Because the ASPNET user is automatically generated when installing ASP.NET, its password is no way to access. If the certificate is included in the current user storage (CurrentUser Store), the server is likely to access the private key. After the server sets the certificate, you will get the client to get this certificate and public key. There is a relationship with your business system and application needs, you can put it on the web to let users download and install them in advance; if the application is available to LDAP or CA.
The client is as follows: MyWebserv.RequestsoapContext.Security.ToKens.Add (Certtoken) 'SOAP message Add encrypted results MyWebserv.RequestsoApContext.security.ements.add (New _
Microsoft.Web.Services2.security.encryptedData (CERTTOKEN)) MyWebserv.WebMethod server After receiving the encrypted SOAP message, the corresponding private key is automatically decrypted. If it fails, it returns a corresponding error. It can be seen that the difficulty of using the certificate plus decryption message is the selection and configuration of the certificate, especially the message receiver.
In addition to supporting the above username / password, the WSE supports two tokens of X509 certificates. It also supports Kerberos Ticket, Security Context token, and user-defined tokens. Kerberos Ticket seems to be WSE's own content, there is no in the standard WS-Security, and only on Windows XP SP1 / SP2, Windows 2003 is supported. The security context token requires an context token service generation. The core of the user-defined token is to derive a user's own token class by SecurityToken, complete various security functions. In short, WSE is to use this token and extended SOAP messages to implement Web Services security.
