XML Web Services Security 

XML Web services are one of the cornerstones of the Microsoft .NET Framework, providing information and services to Web applications through well-defined programmatic interfaces built on standard Internet protocols. A key benefit of XML Web services is the ease with which they can be accessed over the Internet compared to traditional distributed object models.

However, businesses creating XML Web services may not want to make these services freely available to everyone. Access to XML Web services can be restricted to authorized clients in much the same way that Web sites restrict access to authorized users. In addition to restricting access, an XML Web service may need to ensure the privacy of data transmitted to and from clients, as well as protect internal business logic and data stores used to implement the service.

What Are XML Web Services?

An XML Web service is programmable application logic accessible using standard Internet protocols. XML Web services combine the best aspects of component-based development and the World Wide Web. Like components, XML Web services represent black-box functionality that can be reused without worrying about how the service is implemented. XML Web services provide well-defined interfaces, or contracts, that describe the services provided.

Unlike current component technologies, XML Web services are not accessed using object model–specific protocols such as the Distributed Component Object Model (DCOM), Remote Method Invocation (RMI), or Internet Inter-ORB Protocol (IIOP). Instead, XML Web services are accessed using ubiquitous Web protocols and data formats such as Hypertext Transfer Protocol (HTTP) and Extensible Markup Language (XML).

An XML Web service contract describes the services provided solely in terms of the messages that the XML Web service accepts and generates. No information about how the XML Web service is implemented is necessary in the contract. Consumers of an XML Web service do not need to know anything about the platform, object model, or programming language used to implement the service. They only need to understand how to send and receive messages as specified by the XML Web services contract.

There are a few key specifications and technologies you are likely to encounter when building or consuming XML Web services. These specifications and technologies address five requirements for service-based development:

A standard way to represent data

A common, extensible message format

A common, extensible contract language

A way to discover services located on a particular Web site

A way to discover service providers

XML is the obvious choice for a standard way to represent data. Most XML Web service–related specifications use XML for data representation, as well as XML schemas to describe data types.

The SOAP defines a lightweight protocol for information exchange. Part of the SOAP specification defines a set of rules for how to use XML to represent data. Other parts of the SOAP specification define an extensible message format, conventions for representing remote procedure calls (RPCs) using the SOAP message format, and bindings to HTTP. (SOAP messages can be exchanged over other protocols, but the current specification defines bindings for HTTP only.) Microsoft .NET products will use SOAP as the primary message format for communicating with XML Web services.

Note that the current SOAP specification does not define all the features developers might expect to find in a traditional distributed object protocol, such as object lifetime management, distributed transactions, or security. All of these features could be defined as extensions to SOAP, but they are not defined as part of the base specification.

Most Internet-based scenarios should not require stateful objects or distributed transactions, because both place server resources (for example, database locks) under the control of remote clients. In practice, this means that the services exposed by an XML Web service are:

Stateless. All the information required to perform the service is either passed in with the request message or can be retrieved from a data store based on some information provided with the request.

Atomic. Each service represents a complete unit of work that leaves data stores in a consistent state. For example, if clients need to be able to move money between bank accounts, the service should accept a MoveMoney request message, not just Debit and Credit requests.

Given an XML Web service, it would be nice to have a standard way to document what messages the XML Web service accepts and generates—that is to document the XML Web service contract. A standard mechanism makes it easier for developers and developer tools to create and interpret contracts.

Several contract languages were proposed during the past year: Service Description Language (SDL), SOAP Contract Language (SCL), and Network Accessible Services Specification Language (NASSL). All have been supplanted by a new language jointly developed by Microsoft and IBM: the Web Services Description Language (WSDL). WSDL is an XML-based language. Microsoft's developer tools that help create and consume XML Web services are currently being updated to support WSDL.

Developers also need some way to discover XML Web services. The DISCO (for Discovery of Web Services) specification defines a discovery document format (based on XML) and a protocol for retrieving the discovery document, enabling developers to discover services at a known Uniform Resource Locator (URL).

However, in many cases the developer will not know the URLs where services can be found. Universal Description, Discovery, and Integration (UDDI) specifies a mechanism for XML Web service providers to advertise the existence of their XML Web services and for XML Web service consumers to locate XML Web services of interest. There are three parts to the UDDI specification:

White pages, which provide business contact information

Yellow pages, which organize XML Web services into categories (for example, Credit Card Authorization Services)

Green pages, which provide detailed technical information about individual services (this information may be provided by referencing discovery documents or contracts)

The UDDI Business Registry is an implementation of the UDDI specification and is itself an XML Web service that uses SOAP over HTTP as its messaging protocol.

Restricting Access to an XML Web Service

XML Web services can be implemented so that only authorized clients can access them. To restrict access to your XML Web service, you need a way to authenticate clients. Then, based on the credentials presented by the client, you can decide whether to authorize access to the service.

In essence, securing an XML Web service is no different from securing a Web site. But instead of authorizing end users to access the site, you will authorize computers or businesses to access the XML Web service.

If you know exactly which computers need to access your XML Web service, you can use Internet Protocol Security (IPSec) or firewalls to restrict access to computers of known IP addresses. This technique is particularly useful when you want to restrict access to computers in a private network.

In most Internet scenarios, however, you will not know the IP addresses of all your clients. In this case, the most straightforward approach to implementing authentication is to leverage the authentication features of the protocol used to exchange messages. For example, if you are sending and receiving SOAP messages over HTTP, you would leverage the authentication features available for HTTP. Microsoft Internet Information Services version 5.0 supports several authentication mechanisms for HTTP (see www.microsoft.com/technet/iis/authmeth.asp for more details):

Another option is to implement a custom mechanism. For example, if you are sending SOAP messages, you can define your XML Web service contract so that client credentials are passed in the SOAP message itself. With this approach, you need to retrieve the credentials from the message and implement your own authorization logic, but you can use any kind of client account database you want. You can pass client credentials as a SOAP header or as elements in the SOAP body.

Because SOAP messages are XML, if you are using a protocol such as HTTP to send the messages, the client credentials will be passed as plain text. If this is unacceptable, you could use SSL instead of HTTP.

Note that SSL is significantly slower than HTTP alone, so developers should carefully weigh the tradeoffs between security and performance. It is possible to use SSL for some of the operations exposed by an XML Web service and more lightweight techniques for operations where security is less critical.

If the performance overhead of using SSL for all secure operations is unacceptable, another authentication option is to use the SOAP RPC conventions and define a special logon operation on your XML Web service that accepts credentials as elements of the SOAP body and returns a session key. Only the logon method would need to be sent over SSL. Other messages could be sent over HTTP, including the session key either in the SOAP header or the SOAP body. This approach runs the risk that the session key will be hijacked, but reduces the risk that a client's password will be stolen.

You might wonder if Microsoft Passport could be used to restrict access to an XML Web service. In theory, Passport could be used to authenticate clients of an XML Web service. However, Passport currently is targeted at authenticating end users, rather than applications, computers, or businesses. So in practice, you may find that potential clients do not have and are not willing to obtain a Passport.

Some XML Web services will have the need to authenticate end users. In this case, you might expect Microsoft Passport to be useful. However, with the current implementation of Passport, if a Web site is calling your service on behalf of the end user, there isn't a secure way for the user to enter his Passport user ID and password and for the XML Web service to verify that the user is logged in (and obtain the user's profile information, if necessary). In general, if an XML Web service wants to authenticate an end user today, it must rely on client Web sites to pass on the user's credentials.

Protecting Data

In addition to authentication, the SSL protocol adds data integrity and data privacy to HTTP. When SOAP messages are sent over SSL, they cannot be read or modified in transit. If your XML Web service accepts messages containing sensitive information, you may wish to have clients send the messages over SSL.

If the overhead of SSL is unacceptable, another option is to encrypt individual elements of the SOAP body. Digital signatures could be used to ensure that elements of the SOAP body have not been tampered with in transit. At the moment, there is no standard for XML encryption or digital signatures, so you would need to define a custom mechanism that your clients are willing to support.

To further protect the data used by XML Web services, data stores may be kept inside the corporate firewall. Data stores outside the corporate firewall should be locked down as much as possible—for example, by restricting access to the XML Web service and administration programs.

David Chappell's Understanding Windows 2000 Distributed Services from Microsoft Press contains an excellent conceptual overview of how SSL works. For detailed information on providing data integrity and privacy, protecting internal data stores, auditing, and protecting against attacks by unauthorized users, see Michael Howard's Designing Secure Web-based Applications for Microsoft Windows 2000 from Microsoft Press.

ASP Security Features

XML Web services hosted by application service providers (ASPs) use the same authentication and authorization mechanisms described in this document to protect against incoming messages from unauthorized users.

The business logic of XML Web services hosted on Windows-based platforms is often implemented using COM components or managed classes targeting the .NET platform. ASPs can further ensure that this business logic cannot be called directly by running your XML Web services under a specific user account and restricting access to the COM components or managed classes to that user account.

Tools Support

ASP.NET Web services support sending and receiving messages over SSL, along with all the HTTP authentication and authorization mechanisms supported by the .NET Framework network classes, including Basic, Digest, and NTLM authentication. In addition, ASP.NET Web services support Microsoft Passport authentication and custom cookie-based authentication for applications that use a private account database for authentication.

.NET Framework role-based authorization and code-access security can be used by XML Web services implemented using ASP.NET.

The July 2000 release of the SOAP Toolkit for Microsoft Visual Studio 6.0 does not support any HTTP authentication mechanisms. Microsoft expects to release an update to the SOAP Toolkit shortly that adds support for:

Sending and receiving messages over SSL

Anonymous, Basic, and NTLM authentication

Authenticating a client to an HTTP proxy