Building secure Web services using Microsoft SOAP Toolkit 2.0
Kirill Gavrylyuk
Test Team Leader, Web Data SOAP Group
Microsoft Corporation< /p>
July 2001
Abstract: The Microsoft SOAP Toolkit 2.0 provides a flexible framework for building scalable Web services for a variety of intranet and Internet solutions. In both scenarios, security is an important factor in establishing reliable services. SOAP Toolkit 2.0 supports Internet security based on the IIS security infrastructure. This article describes how to use the Microsoft SOAP Toolkit 2.0 to build a security solution.
Table of Contents
Introduction
Important Rules
Authentication
Agent Support and Authentication
SSL and Client Certificates
Authentication Issues
Troubleshooting
Additional Information
Introduction
As with any distributed protocol, the key to a successful SOAP application is obtaining security permissions. The SOAP standard does not specify any security mechanism, but instead delegates security processing to the transport layer. For SOAP Toolkit 2.0, the transport layer is HTTP. SOAP running over HTTP is basically a Web application, much like other ASP or ISAPI applications running on IIS. SOAP's authentication, authorization, and encryption mechanisms are exactly the same as those you normally use in web applications. If you are familiar with web security, you are also familiar with SOAP security. If you're new to web applications, this article will give you enough background to get started. Each topic is covered in great detail. If you need more detailed information, see the MSDN Library or Designing Microsoft Windows 2000 Web-Based Security Applications by Michael Howard, Marc Levy, and Richard Waymire.
Important Rules
We begin by outlining the important rules to follow when building secure Web services, based on the ideas set forth in Designing Secure Web-Based Applications for Microsoft Windows 2000. Secure Web services can be classified into the following seven categories:
Authentication
Authorization
Audit
Confidentiality
Integrity
Availability
Recognition
Authentication is the process by which one entity (also called a subject) verifies that another entity is who it claims to be. SOAP Toolkit 2.0 supports the following authentication methods:
Basic
Digest
Kerberos
Windows NTLM
SSL Client Certificate
SOAP header-based authentication
Proxy Authentication
This document describes how to configure the server and client to use the above authentication methods.
Authorization is the mechanism that provides authenticated users with access to resources. As long as Web services built using the SOAP Toolkit are based on IIS, these services can take advantage of the authorization mechanisms supported by IIS. This document will also describe some issues that users should pay attention to.
The purpose of the audit is to collect information about successful and failed requests to the web service. You can accomplish this using the IIS auditing feature and the SOAP Toolkit tracing feature. This document does not cover this aspect, you can refer to the IIS documentation, netmon logs, and the SOAP Toolkit help for the SoapServer object.
Confidentiality refers to ensuring that attackers cannot see the communication between the client and the server. Integrity is the ability to protect data from being deleted or altered, whether maliciously or accidentally. For confidentiality and integrity, the SOAP Toolkit allows data to be encrypted using Secure Sockets Layer (SSL). This document describes how to enable SSL support on IIS and use it with clients.
Availability ensures that legitimate users are not denied access to requested resources. Examples of availability technologies include load balancing and hardware and software failover.
The SOAP Toolkit has been successfully tested with Microsoft Application Center load balancing software.
Recognition is a technique that provides evidence of an operation that occurred to prevent clients from spoofing or denying transactions. The SOAP Toolkit uses the recognized functionality provided by IIS. This document does not introduce accreditation.
Authentication
This section describes the authentication methods supported by the SOAP Toolkit, including their advantages and disadvantages, and how to set them up. It also describes the known limitations of the SOAP Toolkit on supported platforms, and the behavior of the SOAP Toolkit HTTP connector when the server has multiple authentication schemes available.
How does the authentication handshake work? Each authentication handshake begins as follows:
The client makes a page request.
The server returns status 401 "Access Denied" and a set of HTTP headers.
WWW authenticates every authentication method it supports.
How do I authenticate myself using SoapClient? If the web service requires authentication (Basic, Digest, NTLM, or Kerberos), SoapClient needs to be provided with a username and password to pass to the web service. This can also be done using the SoapClient.ConnectorProperty package:
dim SoapClient
set SoapClient = createobject("MSSoap.SoapClient")
SoapClient.mssoapinit(" pany.com" bypasses any server with .soap-company.com in its name.
A proxy server is required to allow bypassing of any server outside the local intranet. Note that for HTTP and for Proxy servers are different for connections over SSL (HTTPS). The proxy should allow the use of either protocol for SSL to work properly.
Limitations: Using the Microsoft SOAP Toolkit on Windows 2000 and Windows NT4 when using the default proxy. There is a known issue with the 2.0 HttpConnector: it does not understand the "Bypass proxy" list of the default IE proxy settings. If "Do not use proxy server for local addresses" is checked and the hostname specified in the URL does not contain "." Will bypass the proxy server. But it does not understand the complex template specified in the "Exception" text box in the "Advanced" menu of IE proxy settings.
Connecting through the specified proxy
can. Specify which proxy uses the ProxyServer and ProxyPort connector properties:
set SoapClient = createobject("MSSoap.SoapClient")
SoapClient.mssoapinit(". Before initiating an SSL connection, the client The site name will be checked to see if it is the same as the certificate's common name.
Enter the country, province, and city/county location that the certificate authority may check to see if this information is consistent. to ensure that the information you enter is valid. When entering a province, enter the full province name.
Enter the name, email address, and phone number of the person who manages the server. This information is not included in the certificate. The certificate authority requires this information.
The file containing your request is created in Base64-encoded format. During this process, IIS also creates a private key and a public key for the certificate request. Key. The private key will be stored on your computer and the public key will be sent to Verisign with the request and used to encrypt the certificate data.
Go to www.verisign.com (in English). and click "Get Trial SSL ID". When registering a certificate, you will be asked for a CSR (Certificate Signing Request). Copy and paste the content after "BEGIN NEW CERTIFICATE REQUEST;" in your request file, otherwise, an error will occur. Verisign sends you a test server-side certificate via email. The same process applies to commercial certificates, except that it charges a fee and carefully verifies the information submitted.
Ensure that the certificate obtained from the certificate authority is Base64 encoded. If the certificate authority is Verisign, you can obtain the certificate via email.
Create an empty file with a .cer extension, copy everything between and including the lines "BEGIN CERTIFICATE" and "END CERTIFICATE" and paste into the file.
Go to the Properties/Directory Security tab of the site where you want to enable SSL. Click Edit Secure Communications, and then click Key Manager.
In the dialog box, expand the Local Computer node in the tree view, and then expand the WWW leaf to display the key requested by your certificate. Since the certificate is not installed yet, it is marked red. Right-click the certificate and select Install Key Certificate. Select the file with the certificate to install. You will be prompted for the previously set password. Enter your password. Your certificate is now installed.
Enable SSL on the server using IIS 5.0
Right-click the website where you want to enable SSL and select Properties.
On the Directory Security tab, click Edit Secure Communications.
Click "Server Certificate" to open the Server Certificate Wizard. The wizard will remember the current status of the website, such as whether you already have a server certificate. (This assumes you don't have a certificate.)
In the Certificate Wizard, click Next, select Create a new certificate, and then click Next.
Select "Prepare request now but send later" and click Next.
Enter a friendly name for the certificate. This name is not used in the certificate structure, but serves as a way to distinguish the request from the certificate. Select the public key length. The recommended key length is no less than 1024 bytes. Click Next.
Enter the organization name and department name that can be verified by the issuing authority, or a valid name if you are requesting a real certificate for business purposes. Enter the name of the computer to be authenticated. Note: It must be equal to your full site name, such as www.yoursite.com. Click Next.
Enter the country (region), province/autonomous region, city/county location. Please enter valid information and the certificate authority will check that the information is consistent. When entering a province, please enter the complete province name. Click Next.
Enter the request file name used to save the request. Click Next.
A summary of what you entered will be displayed. Confirm that the content is correct and click "Next" to complete the wizard. The file containing the request will be saved in Base 64 format.
The file containing your request has been created. The file is Base64 encoded. During this process, IIS also creates a private key and a public key for the certificate request. The private key will be stored on your computer, and the public key will be sent to Verisign with the request and used to encrypt the certificate data.
Go to www.verisign.com (in English) and click "Get Trial SSL ID". When registering a certificate, you will be asked for a CSR (Certificate Signing Request). Copy and paste the content after "BEGIN NEW CERTIFICATE REQUEST;" in your request file, otherwise, an error will occur. Verisign sends you a test server-side certificate via email. The same process applies to commercial certificates, except that it charges a fee and carefully verifies the information submitted.
Ensure that the certificate obtained from the certificate authority is Base64 encoded.
If the certificate