|
Crosscutting Your Web Service Security
Leverage aspect-oriented design principles to implement robust security in your .NET Web services.
by Tarak Modi
November 1, 2004
Web services allow for an excellent implementation of a service-oriented architecture (SOA). In other words, Web services that encapsulate business functions can be consumed by other systems both within and outside the company (such as by business partners, vendors, and suppliers). As an architect designing these Web services, one of your prime goals is to enforce security. At the same time, you don't want to burden your developers with a cumbersome and abstruse framework. Ideally, they should spend 100 percent of their time creating business services that implement the business logic and rules and not writing any security related code at all. Yes, this is possible, and it's easy to achieve in .NET. In this article, I will discuss a base architecture that realizes all of these goals.
The Three Pillars of the Architecture
The architecture discussed in this article is based on three concepts:
Crosscutting Concerns
A core concept that underlies the architecture involves crosscutting concerns. A "concern" is any concept related to the system. For example, in a banking application, crediting and debiting customer accounts and transferring assets between accounts are concerns. All three of these example concerns are fundamental to the banking system and are consequently classified as "core" concerns. Other concerns in the banking application are related to security, transactions, and logging. These concerns are not specific to any particular process/module within the banking application. Such concerns are therefore classified as "crosscutting" concerns. Typical object-oriented systems do not make a clear distinction between these core and crosscutting concerns because the fundamental unit of design in an object-oriented system is an object, not a concern. Systems that do recognize the distinction between these concerns are known as aspect-oriented systems. In an aspect-oriented system, the fundamental unit of design is a concept. Although aspect-oriented systems are most easily implemented on top of an object-oriented language or platform such as Java and .NET, the methodology of aspects applies equally to structured languages such as C.
Web Service Security Concepts
The problem with Web service security is not that it is particularly difficult to implement. Rather, the problem is that people can't agree on the best way (or specification) to accomplish it. WS-Security, which I use in this article, is one of the more popular specifications available for securing SOAP messages. Microsoft, IBM, and Verisign jointly created WS-Security, and it is an OASIS-approved standard. WS-Security leverages the XML Encryption, Signature, and Canonical standards published by the World Wide Web Consortium (W3C). See the Resources section for links to the specifications for these standards.
WS-Security works by inserting custom XML elements within the header of a SOAP message. These elements are fully defined in the WS-Security specification. The process of (correctly) creating and consuming these header elements can be quite complex. To shield developers from the numerous details involved in using WS-Security, Microsoft created the Web Service Enhancements (WSE) add-on package for .NET. WSE provides a foundation for building applications based on Web services specifications published by Microsoft and industry partners, including WS-Security, WS-Policy, WS-SecurityPolicy, WS-Trust, WS-SecureConversation, and WS-Addressing. The architecture I describe in this article leverages WSE to implement WS-Security. The architecture itself is not tied to WS-Security or to WSE in any way. These are merely used as convenient examples. That said, I believe most .NET developers will probably use WSE for .NET Web Services security because it is available for free from Microsoft.
Back to top
|