Securing XML Web Services Created Using ASP.NET

This topic is specific to a legacy technology. XML Web services and XML Web service clients should now be created using Windows Communication Foundation.

Deciding which security implementation is best for a Web service begins with looking at two key security principles: authentication and authorization. Authentication is the process of validating an identity based on credentials, such as a user name and password, against an authority. When an identity has been authenticated, authorization determines whether the identity is authorized to access a resource.

Web services created using ASP.NET can choose their security options from the authentication and authorization options offered by ASP.NET or customized SOAP-based security. ASP.NET operates in conjunction with Internet Information Services (IIS) to provide several authentication and authorization options. It is also possible to create custom authentication options, such as the use of SOAP headers. Additionally, ASP.NET offers the ability, known as impersonation, to execute a request using the client credentials. For more information about using impersonation, see ASP.NET Impersonation.

This topic summarizes the authentication and authorization options available to Web services built using ASP.NET. For more information about security options available to ASP.NET Web applications, see Securing ASP.NET Web Applications and Building Secure ASP.NET Applications: Authentication, Authorization, and Secure Communication.

For more information about accessing remote resources from ASP.NET-based applications, see the "Impersonation/Delegation Model" and "Trusted Subsystem Model" topics in Chapter 3 of Building Secure ASP.NET Applications.

Authentication Options for XML Web Services

Web services created using ASP.NET have several options for authenticating clients, so the big question is: Which one is right for a specific Web service? In choosing the right security option, one of the things a developer has to choose between is the level of security and performance. For some Web services, it is critical that client credentials are sent over the network using encryption, so an algorithm that encrypts the client credentials is essential. For example, a developer writing a Web service that processes credit cards probably worries more about the client credentials being stolen than the extra overhead of encrypting the credit card data.

The following table is a summary of the authentication options available to Web services built using ASP.NET. Options prefixed with Windows are a part of the Microsoft Windows authentication options available to Web services created using ASP.NET.

Summary of Authentication Options

Authentication option	Description
Windows - Basic	Use for non-secure identification of clients, as the user name and password are sent in base 64-encoded strings in plain text. Passwords and user names are encoded, but not encrypted, in this type of authentication. A determined, malicious user equipped with a network-monitoring tool can intercept user names and passwords.
Windows - Basic over SSL	Use for secure identification of clients in Internet scenarios. The user name and password are sent over the network using Secure Sockets Layer (SSL) encryption, rather than plain text. This is relatively easy to configure and works for Internet scenarios. However, using SSL degrades performance.
Windows - Digest	Use for secure identification of clients in Internet scenarios. Uses hashing to transmit client credentials in an encrypted manner so the password is not transmitted in clear text. In addition, Digest authentication can work through proxy servers. However, it is not widely supported on other platforms.
Windows - Integrated Windows	Uses NTLM or Kerberos. Uses a cryptographic exchange with the user's Microsoft Internet Explorer Web browser.
Windows - Client Certificates	Use for secure identification of clients in Internet and intranet scenarios. Requires each client to obtain a certificate from a mutually trusted certificate authority. Certificates are optionally mapped to user accounts, which are used by IIS for authorizing access to the Web service.
Forms	Not supported by Web services. This is a system by which unauthenticated requests are redirected to an HTML form using HTTP client-side redirection. Most clients of Web services will not want to provide credentials using a UI; you must work around this if you want to use forms authentication.
SOAP headers – Custom	Useful for both secure and non-secure Internet scenarios. User credentials are passed within the SOAP header of the SOAP message. The Web server, regardless of the platform hosting the Web service, provides a custom authentication implementation.

For all options listed above, except the use of SOAP headers, the security settings are specified using a combination of configuration files and IIS. The custom SOAP headers option is detailed following the Authorization section, as that solution involves both authentication and authorization.

Windows Authentication

Both IIS and ASP.NET provide support for authenticating Web applications, including Web services, using security built in to Windows. Windows provides three options for authentication: Basic, Digest, and Integrated Windows. Additionally, each option can be used with SSL. As all Windows authentication options except Basic encrypt the data in some form, the additional level of encryption offered by SSL is typically only used in conjunction with Basic or Client Certificates.

Regardless of which Windows authentication option is used, the procedures for setting up both the Web service and Web service client are similar. For more information, see How to: Configure an XML Web Service for Windows Authentication. No code needs to be added to a Web service to use Windows authentication, as the authentication options are set in a configuration file and IIS. Code to pass the client credentials to the Web service must be added to a Web service client.

If SSL is chosen as part of the authenticating mechanism used by a Web service, SSL needs to be configured for the Web application hosting the Web service or for the Web service itself, using IIS. The service description and, consequently, proxy classes generated from the service description will reflect that the Web service uses SSL (if the service description and service help page are accessed using SSL). The URL to the Web service within the service description will be prefixed with https. For more information about setting up SSL, see the IIS documentation.

Client Certificate Authentication

Client Certificates help provide a secure mechanism for authentication, as clients are required to send an electronic document, called a client certificate, identifying a client using an SSL connection to the Web server. The SSL connection encrypts the client credentials contained within the client certificate as they are sent over the network. Communication between the client and the Web server is encrypted using a combination of the encryption keys sent by the client and keys provided by the Web server. Once the communication is established, only the client and server computers can communicate to each other using that SSL connection.

A client certificate can be obtained from a certificate authority, which can either be the Web server itself or a trusted intermediary between the client and server. Once a certificate has been obtained, and the Web server has been configured to accept client certificates, a client can send the client certificate to the Web server over an SSL connection, when a Web service is called. For more information about client certificates, see the IIS documentation. For more information about setting up Client Certificate authentication for a Web service, see How to: Configure an XML Web Service for Windows Authentication.

Authorization Options for XML Web Services

The purpose of authorization is to determine whether an identity should be granted the requested type of access to a given resource. There are two fundamental ways to authorize access to a given resource: file authorization and URL authorization. File authorization can be used whenever Windows authentication is used, as the permissions are set in IIS on a per-file basis. URL authorization can be used with any of the built-in authentication mechanisms supported by ASP.NET. With URL authorization, configuration is done through a configuration file, where users can be selectively granted or denied access to any files associated with ASP.NET, including .asmx files.

For more information about setting up authorization on a per-file basis, see the IIS documentation.

For more information about setting up authorization using a configuration file, see ASP.NET Authorization.

Custom Authentication Using SOAP Headers

The Windows authentication mechanisms, including client certificates, rely on the HTTP transport, whereas SOAP is transport-independent. Web services built using ASP.NET use SOAP over HTTP, as well as HTTP-POST and HTTP-GET implementations that return non-SOAP XML documents. So, one reason to create a custom authentication mechanism is to decouple authentication from the transport. This can be accomplished by passing the authentication credentials in the SOAP header.

SOAP headers are a great way of passing out-of-band or information not related to the semantics of a Web service. Unlike the Body element of a SOAP message, which includes the in and out parameters for the Web service operation that are processed by the Web service method, the Header element is optional and can thus be processed by the infrastructure. That is, processed by infrastructure developed to provide a custom authentication mechanism.

For a description of one method of using SOAP headers for authentication, see How to: Perform Custom Authentication Using SOAP Headers.

To use SOAP headers for authentication, a Web service client would send its credentials to the Web service by adding the expected SOAP header to the SOAP request and populating it with the client credentials. To use SOAP header authentication, a Web service must do two things: specify that it expects the SOAP header containing the authentication credentials and authorize the client access to the Web service.

See Also

Tasks

How to: Configure an XML Web Service for Windows Authentication
How to: Perform Custom Authentication Using SOAP Headers

Reference

NetworkCredential
CredentialCache
X509Certificate

Other Resources

Securing ASP.NET Web Applications
Building XML Web Services Using ASP.NET