Opening up Web services to the world requires a robust security implementation to stop unauthorised access. Learn about two basic Web services security approaches: channel security and package security.

If you ask development architects from either the Java or the .NET camp about the future of software development, they can finally agree that the future of software development is in applications written for virtual machinesââ,¬"such as the Java Virtual Machine (JVM) or the .NET Common Language Runtime (CLR)ââ,¬"where applications on different platforms are tied together using XML Web services. The days of COM and CORBA interoperability problems will be behind us very soon. But only agreed-upon standards will make this future interoperability possible, and those are six to eighteen months away from being generally adopted and implemented in vendors' platforms. In the interim, developers need ways to allow systems to talk using Web services.

There are two basic ways to implement Web services security. The first is to manage security at the channel level. The second is to modify the package to support security.

Channel security
When using channel security, the developer doesn't need to know anything about the specific implementation. Infrastructure engineers simply use standards-based mechanisms to create a secure conversation between two systems consuming each other's Web services. Channel security has the advantage of being standards-based so that any two platforms can use the same security mechanism regardless of the operating system. The other major advantage is that channel security involves configuration rather than a change to the way developers write code.

There are three disadvantages to using channel security. First, there will be a performance negative impact when the path between two systems is being manipulated by hardware or software to ensure security. For example, using Secure Sockets Layer (SSL) security imposes a 30 to 40 percent performance penalty. The second disadvantage to channel security is that it's protocol dependent. Both sides of the connection need to be able to communicate using the selected protocol. And lastly, many organisations will have to invest in additional infrastructure to support efficient implementation of channel security.

Implementing channel security
There are three basic ways to implement channel security. Using credentials and SSL, you can configure IIS to only allow certain user IDs and passwords to access the URL pointing to the Web service, and then protect it with an SSL certificate. You can gain an extra measure of security by decorating your methods with declarative security attributes that only allow those particular user IDs and passwords to execute the Web services methods.

The second method involves configuring a local certificate server (an optionally installable, but included, service in Windows 2000) and then sending out certificates to the companies that need to access your Web services. You can then use IIS to configure the Web services' virtual directory to accept only requests from other systems possessing these certificates. Finally, you can configure your system to only allow Web services calls over a secure PPTP or IPSec connection. You can use a combination of these methods to increase security, but be aware that the more layers you place on the channel, the more your performance will suffer.

Package security
Implementing package security will have less of an effect on performance, but interoperability will suffer. Package security involves making changes to the SOAP package itself in code. For two systems to talk, they must both understand how to process the modified package. In other words, where channel security involves configuration rather than coding, package security focuses on coding instead of configuration.

Implementing package security
There are three ways to implement package security. First, you can implement custom SOAP headers. Implementing custom SOAP headers allows you to embed security information into the header and then reject the SOAP package if the information isn't found. The .NET Framework makes it simple to implement customer headers. You need only to inherit from the SoapHeader class and use the SoapHeaderAttribute to describe your new header. The .NET Framework will automatically generate the required proxy class and WSDL to support your new header. Rather than changing the contents of the SOAP message, you can simply encrypt the entire message. Configuring encryption at the package level requires that the server and client have access to the public and private keys necessary to encrypt and decrypt the secured packages and that they use standard encryption algorithms.

The final method for implementing package security is much more complex, but will make more sense for companies that already have a significant investment in Microsoft's Internet Security and Acceleration Server (ISA). ISA has the ability to implement custom filters that can validate SOAP requests, perform method level authentication, and even cancel method invocation in cases where the filter detects an anomaly. Unfortunately, the current version of ISA requires that the filters be written as ISAPI filters using Microsoft C++, a skill set few developers possess. Still, this is the most secure way to implement package level security; if you have access to the skills and have an existing or planned ISA infrastructure, I would highly recommend it.

Making your choice
Many companies will opt for the channel-based method because most Web services implementations are with known partners to whom they are willing to issue credentials necessary for validation. Packet-based methods are best for internal implementations where you can control both sides of the development effort and you need more granular control of the security. When planning your Web services based systems, you'll probably find ways to implement both now that you know the options and the pitfalls.

Copyright © 2009 CBS Interactive, a CBS Company. All Rights Reserved.
ZDNET is a registered service mark of CBS Interactive. ZDNET Logo is a service mark of CBS Interactive.