Sharing structured data

XML Magazine

Subscribe to XML Magazine: eMailAlertsEmail Alerts newslettersWeekly Newsletters
Get XML Magazine: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


XML Authors: Peter Silva, Stackify Blog, Mamoon Yunus, Progress Blog, XebiaLabs Blog

Related Topics: XML Magazine, SOA & WOA Magazine

XML: Article

Secure Service-Oriented Architectures

BizTalk Server 2004 can play a vital role in building agile SOAs

BizTalk Server 2004 promises to be an invaluable tool for delivering on the promise of service-oriented architectures (SOAs): the agile enterprise, able to respond quickly to ever-changing business requirements. BizTalk is an enterprise application integration product whose reliance on XSD and XML means it is a natural integration tool for an SOA built from Web services.

But Web services technology is just coming of age - only recently have products become available that implement the WS-Security standards for securing Web services. Microsoft provides an excellent product, the Web Services Enhancements 2.0 (WSE), which implements the WS-Security and related WS-Policy standards (among others).

Without secure Web services, service-oriented architectures will not be widely implemented - they will always be condemned to the purgatory of the proof of concept. This article discusses techniques for combining BizTalk with WSE so that secure SOAs can be built.

Service-Oriented Architectures
We build traditional applications as isolated silos of functionality, for example an accounting system or an HR management package. Modern applications are constructed with layered architectures to improve maintainability/reliability, but this approach does not address the problems of integrating the isolated applications into a cohesive enterprise information architecture. Figure 1 illustrates how three isolated, three-tier applications are combined with limited interapplication communication to form the IT infrastructure of a simple enterprise.

This traditional approach gives rise to a number of problems: limited interapplication communication and a rigid information architecture. It is these problems that the service-oriented architecture is intended to address.

The SOA focuses on defining contracts for consuming and producing business documents, rather than on creating client/server applications for manipulating data. The SOA makes services available on a network using widely accepted standards (e.g., WSDL, XML, XSD, UDDI, and HTTP) and allows applications to discover and bind to active services (by way of UDDI and WSDL) to create loosely coupled enterprise processes.

Instead of vertical silos of functionality, the SOA allows silos to be broken up into groups of services producing/consuming business documents for a particular business area or partner business. The traditional layered applications can then be replaced by processes that make use of services that span the business areas. Figure 2 illustrates how the previously isolated application stacks have been broken up into groups of services and how new services are built to orchestrate interactions with the lower-level services. Note how an end-user application can be constructed by adding a presentation layer at any level in the SOA.

Figure 2 introduces a new technology layer - the orchestration infrastructure. This is BizTalk's role in the SOA. You can build an SOA without orchestration - the higher-level services can have hard-coded logic to manage the lower-level service interactions - but orchestration allows the SOA to change rapidly to meet ever-changing business requirements. In this way, the SOA supports the goal of creating the "agile enterprise."

BizTalk Server 2004 is a very flexible and powerful tool for constructing an agile SOA. It provides facilities for consuming Web services and exposing its orchestrations as Web services - in this way building bigger services from little services. Moreover, its adapter framework enables Web service facades to be created for legacy applications and data sources. It does all of this with its simple drag-and-drop orchestration designer and graphical data mapping tools.

BizTalk is an ideal enabling technology for creating an agile SOA, but we mustn't lose sight of the fact that today's SOA will be built upon Web services technology and we must be able to build securely on this foundation.

Web service technology is still maturing, and support for routing, addressing, and transactional support is still in its infancy. However, Web services security has now reached a level of maturity that makes the technology practical to use. The question we need to address is how we can use it to build an SOA, and consequently, how Web services security can be integrated with the use of BizTalk Server.

Web Service Security
Web services security, as embodied by the WS-Security and WS-Policy standards, is the most mature of the OASIS standards consortium specifications for augmenting Web services technology. WS-Security is a specification for adding security information to the SOAP envelope header to support the identification of the sender, message signing, and encryption. WS-Policy is a specification for demanding which characteristics a received SOAP envelope should have. In particular, WS-Policy provides a mechanism for demanding certain WS-Security standards.

Microsoft produces a product known as the Web Service Extensions 2.0 (WSE) that implements WS-Security and WS-Policy. WSE supports user/password and Kerberos identification, X509 digital signatures, and X509 or symmetric key encryption. Moreover, WSE is an extensible system in which custom security token handlers can be configured into the message-processing pipeline. In addition to support for WS-Security and WS-Policy, WSE also support WS-Routing, WS-Trust, and WS-SecureConversation.

WS-Security provides a facility for end-to-end security and not simply point-to-point security. Secure Sockets Layer (SSL), the protocol commonly used with secure Web sites, is an example of point-to-point security. SSL works by encrypting all of the data sent over the wire using asymmetric key technology. It is not possible for intermediary routers or firewalls to process the data other than to blindly forward it to the designated endpoint. As a matter of fact this point-to-point security makes many corporate intranets insecure, as opaque channels of communication can be set up through firewalls using SSL.

As SOA technology matures there will be more and more requirements for sophisticated intermediary processing of SOAP envelopes (for example WS-Routing, WS-Transaction, etc.). In order to support SOAP processing intermediaries but to enable end-to-end security, the WS-Security standard specifies how security tokens can be added to the SOAP header without obscuring other header information such as routing or addressing information.

The most important aspect of WS-Security is the ability to sign and encrypt messages using asymmetric keys. WSE supports this capability by the use of X509 certificates.

Digitally signing a message is the process of adding metadata to the message body that proves that the message was sent by the asserted sender and that the message has not been tampered with in flight. There are many options for signing a message, but the basic process is as follows (see Figure 3). The sender of the message obtains an asymmetric key pair from a certificate authority. The key pair consists of a public and a private key. The message sender distributes the public key to all of the recipients to whom they intend to send signed messages.

The sender then computes a hash of the message body and encrypts the hash using their private key. The encrypted hash is combined with the message body to form a digitally signed message that is transmitted to the intended recipient.

The recipient uses the sender's public key to decrypt the signature to retrieve the hashed value. The recipient then recalculates the hash of the message body and compares this with the sent hash. If the hashes match, then the recipient can be certain of two things. First, the expected sender sent the message (only the sender would be able to encrypt the hash with their private key), and second, the message was not tampered with in flight (as any tampering would cause the calculated hash value to change).

Encrypting a message with an asymmetric key (see Figure 4) uses a similar process, but in this case the sender makes use of the recipient's public key to encrypt the message. The key metadata is added as a header to the SOAP header, and the encrypted body is sent in the SOAP envelope.

The recipient, on receipt of the message, will use their private key to decrypt the message. In this scheme, the recipient distributes their public key to all senders with whom they wish to communicate securely.

Note: To digitally sign a message the sender uses their private key, and the receiver uses the sender's public key. Conversely, for encryption the sender uses the recipient's public key, and the recipient decrypts using their private key. This reversal in the usage of public and private keys leads to a common situation in which messages are signed and encrypted in both directions.

As well as signing and encrypting a message, WS-Security specifies (and WSE supports) security tokens in the SOAP header that identify the message sender using a username/password or a Kerberos ticket. The standard also supports tokens that specify how long the message is valid, in order to foil replay attacks.

WSE is a powerful and flexible implementation of WS-Security that can be integrated with BizTalk orchestrations exposed as Web services.

Exposing a BizTalk Orchestration as a Secure Service
BizTalk orchestrations send and receive data by way of ports. Ports are configured, either at design time or during deployment, with a processing pipeline and a transport adapter. The pipeline is responsible for encoding/decoding and assembling/disassembling messages, as well as validation and party resolution. The adapter is responsible for communicating with the chosen message transport mechanism. This approach is easy to understand for a simple adapter like the supplied file adapter, which can monitor a directory or subdirectory looking for new or modified files matching a configured pattern and processing the changed file's contents.

Exposing an orchestration as a Web service is a little different. The supplied SOAP adapter is not the endpoint for the exposed Web service. By analogy with the file adapter you might imagine that the SOAP adapter would listen for incoming HTTP requests, but clearly this would conflict with other Web services and Web applications being hosted by Internet Information Server (IIS). Consequently, the SOAP adapter relies on a wizard-generated ASP.NET Web service stub to expose the Web service interface, which in turn simply invokes the SOAP adapter. The BizTalk Web Services Publishing Wizard implements this mechanism by creating a Web service proxy (i.e., an .asmx file and associated code-behind file) that derives from the Microsoft.BizTalk .ServerProxy class, which in turn derives from the standard System.Web.Services.WebService class. The BizTalk server proxy creates a BizTalk message and adds any SOAP headers into the message context, then invokes the SOAP adapter.

Figure 5 illustrates the components that cooperate in exposing an orchestration as a Web service. The fact that BizTalk orchestrations are exposed as Web services using the standard ASP.NET infrastructure is good news from a security point of view. We can add WSE security into this processing pipeline in the same way that we can add it on to any other ASP.NET Web service.

Microsoft's WSE uses ASP.NET's SOAP extension handler to intercept incoming (and outgoing) SOAP envelopes so that it can process WS-Security headers. If you have WSE installed on your development machine and you right-click on a Web service project in Visual Studio, you will see a new menu option "WSE Settings 2.0...". This menu option allows you to enable both Web service enhancements and Web service enhancement soap extensions for the project. The former adds a reference to the installed WSE assembly; the latter adds WSE as a SOAP extension to the project by adding the configuration section shown in Listing 1 to the web.config file (see Figure 6).

Thanks to BizTalk building on top of the standard ASP.NET infrastructure we can factor WS-Security into exposed Web services using the declarative approach of web.config settings. But this isn't quite the whole story - how can we make use of the results of WSE's authentication processes downstream in the orchestration?

One obvious goal would be to pass the authenticated user's security principal information downstream. The .NET Framework uses objects called security principals, which implement the IPrincipal interface, to hold the identity and associated roles of an authenticated user. WSE sets up security principal objects in some of the WS-Security tokens processed in the incoming SOAP envelope.

In order to make the security principal information available to the orchestration the principal would need to be added to the context of the message created by the server proxy. Getting the principal object into the message context turns out to be a fiddly business because the interface to the BizTalk Server proxy does not provide a facility for adding arbitrary elements to the context of the message it creates. Because of this problem, we must trick the server proxy into adding the principal into the message.We do this by passing the principal object to the server proxy as a SOAP header object. When the server proxy is invoked with a collection of SOAP headers it serializes the objects, using the XMLSerializer, and adds them as named elements in the message context.

There is one problem with this approach when it comes to IPrincipal objects - the standard implementations (WindowsPrincipal and GenericPrincipal) lose their role information when they are serialized using the XMLSerializer. To solve this problem we write a transform function to convert principal objects to our own custom principal implementation, which will serialize without any loss of information. Details of this transform process will not be described here, but you can examine the details in the sample code.

To use this trick for adding the principal into the message context we create our own server proxy class that derives from the BizTalk server proxy and overrides its Invoke method. Our server proxy simply finds the security token in the SOAP request context that holds the security principal, then adds it into the input SOAP header collection that it passes to the BizTalk server proxy (see Listing 2).

The only piece of this puzzle left to address is how to create a convenient method for accessing the principal from within the orchestration. To do this we create a simple class (see the SecurityContext class in Listing 3) that has a static method for deserializing the principal out of the message context. An orchestration creates a variable of type IPrincipal and uses an expression shape to use the SecurityContext class to set this variable. The orchestration can then use the principal's identity or its IsInRole method in its business process. The sample code demonstrates this approach with its SimpleOrchestration example.

As part of the process of designing an orchestration, BizTalk allows the designer to create pipelines by dragging pipeline components into the various message processing stages. With the principal in the message context it is possible to create custom pipeline components that make use of the security principal information. For example, it would be possible to create an authorization pipeline component that uses identity and roles information to check access to the orchestration against some entitlement database. Another example would be to create a party-resolution component that uses the principal's identity to find a configured party in BizTalk's party catalog. By resolving a party for the identified user, the orchestration can route response data using channels appropriate for the party.

Figure 7 shows how all of the components I have discussed integrate with BizTalk to expose orchestrations as secure Web services.

Consuming Secure Web Services
I have shown that it is a simple matter to add WS-Security to an orchestration exposed as a Web service, although it is fiddly to pass the results of authentication downstream. However, this is really only half of the story. If we are going to use BizTalk as the orchestration infrastructure for an agile SOA, we need to be able to consume secure Web services as well as expose secure Web services. Unfortunately, there is no easy way to build this facility into BizTalk. To understand why, you need to understand how BizTalk consumes insecure Web services.

To consume a Web service from an orchestration you add a Web reference to the orchestration and then add a solicit-response port to the orchestration that uses the Web reference. In a normal .NET Framework application, adding a Web reference generates a proxy for the Web service in a file called Reference.cs. The proxy code is derived from the System.Web.Services.Protocols.Soap HttpClientProtocol class, which handles the creation of the SOAP envelope sent to the Web service.

If BizTalk used this mechanism, then it would be possible to edit the generated proxy to derive from our own class, which could implement the WS-Security requirements (making use of the facilities of Microsoft's WSE, of course). Regrettably, when a Web reference is added to an orchestration this code is not generated, instead an XLANG specification of the reference is added, and the proxy code is generated and compiled into the orchestration assembly during the build. Figure 8 illustrates how the existing BizTalk components cooperate to consume a Web service.

As a consequence of the way BizTalk consumes Web services, the only option for consuming secure Web services is to write a secure version of the existing SOAP adapter. Developing such an adapter is a nontrivial job that is beyond the scope of this article, but I am considering writing such an adapter in the near future.

Conclusion
I have discussed how BizTalk can play a vital role in the construction of agile service-oriented architectures (SOAs) by building long-lived processes from subservices and legacy applications. I have also discussed how it is essential that BizTalk can expose its orchestrations as secure Web services and also consume secure Web services.

I've shown that WS-Security can easily be layered on top of exposed Web services (and shown how to pass security information downstream) and I have regrettably concluded that there is no simple way to securely consume Web services from within orchestrations. With the addition of a secure SOAP adapter to plug this gap, BizTalk will be an ideal tool for constructing not just the agile SOA but also the secure SOA.

More Stories By David Regan

David Regan is a freelance systems programmer specializing in data- and rule-driven multitier systems.

Comments (1) View Comments

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.


Most Recent Comments
hung 05/04/04 12:10:29 PM EDT

Very good article.

Just that your source code need to be in a project format so that I can see the whole thing compiled and learn from it.
I also sent this article to Scott Woodgate so that Biztalk team will improve it based on your input.
Excellent article