In recent years, few technological concepts have generated as much excitement as XML and Web services. After the initial excitement and onslaught of developers creating "Hello World" applications and (unfortunately) posting them to a multitude of UDDI directories, there was a general eagerness to apply this skill to real business problems (and we're not talking about online Celsius-to-Fahrenheit calculators).

What better way to finally solve a piece of the remote messaging puzzle that had eluded us than to use this seemingly straightforward, platform-independent concept called Web services? While DCOM and CORBA resolved some of the logistics surrounding distributed applications, the actual solutions could be painfully difficult to implement in the real world, or unsuitable to a multiplatform environment.

One of the first Web services infrastructures we designed for an enterprise client addressed many of the remote messaging challenges of the "old world" and, being particularly proud of how we had overcome some significant technical challenges (that would have been next to impossible using DCOM), we presented it to our security specialist. His first reaction was, "Is SSL over HTTP our only option?"

His point: SSL over HTTP carries additional overhead and as a transport-level solution only operates at that layer.

How then do we address message authenticity, encryption, and integrity in a standardized way? These are typical requirements for message-based applications, and if you haven't already experienced a formal requirements document that references each of these (in excruciating detail), then you will - and sooner rather than later.

Many solutions to these requirements involve using Web server-administered authentication (such as HTTP Basic Authentication) and encryption (such as SSL). However, some security requirements, such as nonrepudiation, can be managed only on an implementation-by-implementation basis using application-specific algorithms.

But does this satisfy typical enterprise standards, requirements, or more important, the guy down the hall dubbed "security officer"? Probably not. Then what can we do to appease the concerns of the security conscious?

WS-Security, Etc.
WS-Security was the first coordinated attempt to standardize Web services security by discussing the encryption and signing of SOAP messages. A collaboration between Microsoft, IBM, and VeriSign, it has since been supplemented with additional specifications, including WS-SecurityPolicy, WS-SecureConversation, and WS-Trust. In this article, we will explore only WS-Security in its most basic form and what it means to an application or solution architecture based on .NET.

At its core, WS-Security addresses two important issues within the Web services space: message integrity and message confidentiality. Message integrity leverages W3C's XML Signature specification, while message confidentiality is implemented through use of XML Encryption. Both use the concept of security tokens to implement these concepts.

According to RFC 3275 (www.ietf.org/rfc/rfc3275.txt), XML Signature is designed to essentially offer a framework to sign a whole or any part of XML data. In more formal terms, XML Signature is "a method of associating a key with referenced data." The benefit here is that we are able to not only sign an entire transaction (as we might do using SSL over HTTP), but we have the option of signing only specific elements of the message. For instance, we can sign all identifying aspects of a document (a user name, a credit card number, a social security number, etc.) without having to sign the document's entire payload, which eliminates a vast amount of overhead. Further, we can sign particularly sensitive elements of the document with one key and sign the document (perhaps using SSL) as a whole with a more general key to meet broader security requirements. Now the security guy down the hall is happy.

Just as XML Signature by definition addresses authentication, authorization, and message integrity, the XML Encryption specification addresses message confidentiality. XML Encryption accommodates the encryption of arbitrary data represented in XML form, including an XML document, an XML element, or the content of an XML element. One appealing aspect of XML Encryption is that we can encrypt any one or more elements of our data in a normalized and structured manner while maintaining the unencrypted integrity of the remainder of the document, for instance, the example used in the W3C recommendation (see Listing 1).

We see here that Mr. Smith's name may not be sensitive, but certainly his credit card number is. In this case the entire CreditCard element has been encrypted (including the element name) to ensure privacy. An alternative to this may have been to encode only Mr. Smith's credit card value itself, at the risk of exposing the fact that it is the CreditCard element being encrypted (see Listing 2).

The issue here is that Mr. Smith may not be comfortable knowing his credit limit is effectively exposed to anyone monitoring transport- or application-layer transactions on this host, as only the content of the element is encrypted, whereas the element attributes are not.

Notwithstanding this example, we can see how versatile this concept is and how specific application requirements could call for specific encryption schemas.

Now that we have a powerful set of standards and specifications at our fingertips, we merely have to commit the related RFCs, specifications, and recommendations to memory and start coding, right?

WSE 2.0
Luckily, we don't have to break out a library of RFC documents, specifications, and recommendations to start implementing our first secure Web services solution. Microsoft has abstracted these specifications and wrapped many of the related concepts and features in the form of the Web Services Enhancements (WSE) complement to the .NET Framework (specifically, version 2.0 of the package) and an eventual add-on for Visual Studio .NET.

This means that with the help of a few select namespaces within our .NET source code we have the ability to implement all of the specifications supported within the WSE. Combined with Intellisense and MSDN documentation, this allows us to have a solution compiled and deployed in record time.

While it should be noted that as of this writing version 2.0 of the WSE was still at the technology preview stage, some of the features of particular note include the concept of policies and what Microsoft has called "message-based programming." These two areas of functionality are likely to be the most significant insofar as distributed transaction processing and extensibility/maintainability are concerned.

Policies
Addressing the most recent version (1.1) of the WS-Policy submission authored by Microsoft and IBM (supplemented by SAP and BEA representation), the WSE toolkit abstracts the ability to communicate the requirements, capabilities, and preferences of any Web service.

An interesting concept is what is called a "policy assertion." This is the most atomic element of a policy, and typically embodies the specifics of a requirement, capability, or preference. An example of a policy expression is shown in Listing 3. This policy contains five assertions, including a text encoding assertion, a specification version, and an XOR (exclusive-or) assertion for selecting exactly one of a set of three language assertions.

Message-Based Programming.
The WSE package also provided tools to assist with the development of asynchronous communications in which concepts such as long-lived transactions, batch processing, and event-driven application models will find new levels of support. This is great news for those tasked with integrating business partners, or even disparate applications that cross not only network boundaries but also environments and platforms.

The Challenges
The authors of these specifications and standards still strive for wider acceptance, and though they are supported by some of the titans of the software world, they are under continuous improvement, which for the typical software engineer means constant software updates to stay in step with these advancements. Microsoft's WSE toolkit is capable of addressing these needs at design time, but this does not address the need to distribute configurations modified in real time to support dynamic security requirements.

To mitigate the impact of these changes to the specifications, the authors have tried to build an extensive model, allowing the designers of specific implementations some degree of flexibility. However, we will be seeing continuous modification and improvement even of Microsoft's WSE package.

It is also important to note that application-specific implementation of security is only half the solution. Typically, a security context is required for an overall solution, particularly if it involves more than one organization or application. Microsoft's WSE toolkit does not explicitly address the requirement to deploy solutions (particularly if platform independence is required) to trading partners or remote distributions.

A perfect world is one where everyone develops integration points on common platforms, using common interfaces over common protocols with the same security context. This obviously is the ideal, and the simple fact is that none of this is the case.

Wouldn't It Be Nice If...
Wouldn't it be nice if software engineers were able to actually create algorithms that reflected business logic and business processes?

"Of course," you say, "that is part of the job description."

Unfortunately, software engineers are typically asked to focus a significant amount of their overall effort on implementation of either security standards/requirements, or transport-level support. This is neither effective nor gratifying for your typical software engineer.

Granted, much of this has been abstracted through the use of development frameworks and packages such as the .NET Framework, which address specific functionality. This still leaves security management squarely in the hands of the engineer. We're going to go out on a limb here, but we believe we're doing the general developer community a favor: security implementation should be the responsibility of security officers or administrators.

With the constant improvements and changes in development frameworks such as .NET, software engineers are busy enough staying on top of changing requirements for business logic without also subscribing to the fickle ebb and flow of the standards bodies and the alphabet soup of acronyms that represent them: WS-I, W3C, OASIS, IETF, etc.

Implementation of security standards is much safer in the hands of specialists. Speaking as software engineers ourselves - they can have it!

Options exist today that support this concept in response to a growing need in a world of disparate, multiplatform, and remote services. Notably, the notion of a network Web services appliance is an ideal vehicle to implement, manage, coordinate, and provision Web services.

Consider a control panel for the administration and publication of Web services that manages access to these services and wraps transactions with the specified security model at runtime. Add to this the ability for such an appliance to abstract any version of a public specification for security, routing, and transaction handling by simply downloading a service pack or module. Additionally, allow this appliance to communicate with other trusted appliances, sharing policies within a "trust federation" automatically, requiring no user interaction. This is an example of Web services solutions available from such innovators as Layer 7 Technologies with their SecureSpan Gateway product that implements security and policy management, and others such as Reactivity that focus more exclusively on security.

By the time you read this article we will be happily developing business logic... right?