As the popularity of Web services increases, the security of Web service transactions is becoming a major concern. With a plethora of standards bodies and organizations working on different security standards and technologies for faster adoption of Web services, it is becoming increasingly difficult for Web services publishers and designers to choose the most appropriate security solution for their Web services. Hosts of options are available with the Microsoft .NET platform to secure Web services. You can choose from platform-specific options, transport protocol­based options, or message-based security options. The choice depends on various factors. This article provides a summary of options available for .NET Web services and discusses suitable scenarios, and the advantages and disadvantages of each. It also provides a status report on the latest security option (WS-Security) in the Web services world.

Introduction
SOAP specifications do not address how security should be implemented in a Web service. This restriction (if you want to call it one) gives you as a Web service publisher or designer a lot of flexibility in terms of implementing a security mechanism that meets the needs of your system. With SOAP and the .NET Framework, you can do this while still providing a high level of security. You should do a risk assessment for your Web service and decide on the level of security required for it. The goal should be to provide adequate security at a price that makes sense for the level of risk, without compromising too much on performance.

The Microsoft .NET platform provides a host of options for securing Web services. You can choose from IIS and ASP.NET (platform-specific options), SSL (a transport protocol­based option), or WS-Security (a message-based security option). The exact choice depends upon various factors such as whether the Web service is going to be published on an intranet or the Internet, whether it is a homogeneous or a heterogeneous intranet, what type of transport is used to expose the Web service, and whether the clients have to pass through any intermediate nodes before reaching the ultimate destination.

IIS- and ASP.NET- Based Security
IIS offers several authentication methods, such as Anonymous, basic, Digest, Integrated Windows, and certificates. IIS can also be configured to provide access based on IP addresses. ASP.NET provides Windows, Forms, and file and URL authorization. ACL (access control list) and .NET roles can also be used to authorize a caller.

IIS and ASP.NET authentication mechanisms are sufficient if the Web service is in a homogeneous intranet within a Windows domain and all clients are using Internet Explorer. For heterogeneous intranets, the choice is limited to basic or certificate authentication. However, IIS and ASP.NET security may not be sufficient for the Internet environment. Another issue with this approach is that IIS does not provide data confidentiality and integrity. SSL should be used with IIS if data confidentiality and integrity are required.

SSL for Secure Communication
SSL is a transport protocol­based option, used to secure communication over the Internet by securing the underlying transport. SSL supports authentication, encryption, and integrity. With client certificates, two-way authentication can also be done using SSL. Digital certificates offer greater security. However, this should be avoided in intranet scenarios, as the costs of setting up the certificate infrastructure and maintaining it can outweigh the benefits.

SSL can be used if your Web service is within a corporate intranet and there is a need for confidentiality and integrity. SSL is a good choice for extranets and Internet Web services if HTTP is the only transport used to expose your Web service, and intermediate nodes are not involved. The ease of use of SSL has made it very popular for simple Web services. However, SSL cannot provide an end-to-end security context for Web services with intermediate nodes.

A limitation of SSL is lack of support for nonrepudiation and authorization. Because of its tight coupling with HTTP transport and its point-to-point security architecture, SSL is not a good choice for Internet Web services that need to be exposed on multiple transports or where intermediate nodes are involved. SSL supports complete message encryption, but there is no support for partial encryption. Hence, intermediate nodes have to decrypt everything before routing it to the next node. This poses a threat to confidentiality of data that must be seen only by a specific receiver. Performance can be another issue when using SSL, specifically during the handshake process.

WS-Security
WS-Security is the security specification of Global XML Web Services Architecture (GXA), jointly developed by IBM, Microsoft, and VeriSign. WS-Security specifications describe how to attach security tokens to SOAP messages and how to transport them from client to server. WS-Security proposes to send security information by adding security tokens that flow in SOAP headers. No specific type of token is required by WS-Security. The security tokens may include Kerberos tickets, X.509 certificates, SAML tokens, or custom binary tokens. WS-Security is based on existing security standards like XML Signature and XML Encryption. Message integrity and nonrepudiation are provided by leveraging XML Signature. Similarly, message confidentiality is provided by leveraging XML Encryption in conjunction with security tokens.

If your Web service needs to be exposed on multiple transports in a heterogeneous environment or if intermediate nodes are involved, then WS-Security is the best option to secure your Web service. It supports partial encryption. Its transport-neutral nature makes it ideal for instances where a Web service needs to be exposed on multiple transports like HTTP, SMTP, or FTP. WS-Security provides an end-to-end security context for Web services with intermediate nodes, and ensures that these nodes can read only those parts of a message that is meant for them, and not something that is meant for the ultimate receiver. It is based on existing security technologies such as X509 certificates and Kerberos. Organizations can leverage their existing security infrastructure to secure their Web services. Use of WS-Security will contribute to an increase in interoperability across languages and platforms because it is based on XML, which is already a W3C standard.

Currently WS-Security does not support single sign-on. Microsoft Passport is a good option if a Web service needs single sign-on capability. However, use of Passport hinders interoperability. Performance can also be an issue when using WS-Security, since each message needs to be secured independently.

At present, WS-Security is in the Recommendation stage. Hence, there might be changes in the specifications suggested during the standardization process. This means that early implementations and adoptions may need to be changed once it becomes a standard. WS-Security is not a complete security solution. There are other issues ­ such as exchange of security tokens, key management, authorization, trust, federation, and privacy ­ that are not answered by WS-Security. Work in these areas is under way.

Microsoft is also working on a project, code-named TrustBridge, that will support federated identities to securely recognize and leverage user identities, thus enabling single sign-on across disparate applications and hosts. Federation will also allow an organization to share its confidential user identities with other trusted organizations in a secure manner, with a single sign-on.

Status of WS-Security and Supporting Specifications
The WS-Security specifications were made public in April 2002, and were submitted to OASIS in June 2002. Currently, the specifications are being reviewed by the technical committee.

Public drafts were made available for specifications supporting XML Tokens for WS-Security in August 2002, and in December 2002 for WS-SecurityPolicy, WS-Trust, and WS-SecureConversation. However, specifications for WS-Federation, WS-Authorization, and WS-Privacy are still pending.

WS-Security Toolkits
Implementation of WS-Security specifications is available in the form of toolkits from different vendors. Examples include Microsoft's Web Services Enhancements 1.0, IBM's Web Services ToolKit 3.3.2, and VeriSign's Trust Services Integration Kit. These toolkits provide APIs to implement security in Web services as per WS-Security specifications. With these toolkits, you can attach security tokens to messages. In addition, you can encrypt and sign messages using these tokens. Apart from this, most of the processing (password comparison, decryption, signature verification, etc.) is done behind the scenes by such toolkits. Web Services Enhancements 1.0 (WSE 1.0) is the WS-Security implementation toolkit from Microsoft for the .NET platform. At present, it is not very well integrated with Visual Studio .NET. Developers need to download another tool to set up Visual Studio .NET projects that use WSE 1.0. Settings can also be done manually.

Currently, the biggest limitation of WSE 1.0 is that attachments are not secured by default. Developers have to ensure that confidential attachments are encrypted before attaching them to messages. Other major issues with WSE 1.0 are the inability to encrypt anything in the security header and a lack of support for Kerberos and SAML tokens. While working with certificates and WSE 1.0 you can come across many issues with respect to certificates setup, access to security keys, and the like. The supporting documentation may not be sufficient for all scenarios.

Microsoft and IBM have together conducted successful interoperability tests between their toolkits. Neutral parties are also conducting their own tests. All these tests indicate that a .NET Web service can authenticate requests from Java clients and vice versa, if both client and service use WS-Security for authentication and the request from the client is as per the security policy of the service provider.

Other Security Concerns
WS-Security and supporting specifications address security issues that need to be dealt with at each Web service level, including authentication, authorization, integrity, confidentiality, and nonrepudiation. Firewalls should be used for generic issues such as denial-of-service attacks, intrusion detection, and virus checking. In addition to firewall functionality, Microsoft's ISA (Internet Security and Acceleration) Server also provides support for application filters. Using these, you can filter SOAP requests for valid values, check for viruses, and perform authentication. ISA Server can be configured for alerts against some specific types of intrusions. You can also leverage the recycling features of IIS 6.0 to handle denial-of-service attacks. IIS 6.0 supports automatic recycling of worker processes based on different parameters like memory usage, CPU usage, scheduled time, elapsed time, and number of requests served.

Making the Choice
The best security method depends greatly on the requirements of the Web service you are going to implement. Table 1 provides an overview of all the options. Select the best option based on the features required for your Web service.

Conclusion IIS- and SSL-based security can be sufficient for securing Web services in intranet scenarios. They can also be used in extranet and Internet scenarios, where intermediate nodes are not involved. WS-Security is the best option for securing Web services on the Internet with intermediate nodes. Currently, WS-Security provides basic security features such as authentication, encryption, integrity, and nonrepudiation. If a complete security solution for your Web service is needed to take care of other issues ­ like token exchange, key management, authorization, and federation ­ and your business requirements do not permit you to wait for the WS-Security specifications to evolve, then a custom security solution is the best option. (However, this will hinder interoperability and increase development effort.) Early adopters of WS-Security might have to undergo changes since WS-Security is still in the recommendation stage.

With so many options available, you can also roll your Web service outside corporate intranets. While your existing security infrastructure may not be sufficient in all scenarios, you can build upon it and take full advantage of integration and interoperability benefits offered by Web services technology.

The views and opinions expressed here are the personal views and opinions of the author, and are not necessarily the views and opinions of Infosys Technologies Ltd.

References

• Reference Architecture for Securing Web Services in a Heterogeneous Environment

• Figure 1