ONJava.com -- The Independent Source for Enterprise Java
oreilly.comSafari Books Online.Conferences.

advertisement

AddThis Social Bookmark Button

WS-Security in the Enterprise, Part 1: Problem Introduction

by Denis Piliptchouk
02/09/2005

Introduction: The Need

This article begins a series related to the details of implementing and using Web Services (WS) Security-based protection in enterprise environments. Such environments are characterized, among other things, by the presence of access control mechanisms protecting the company's web services. Recommendations and designs in this series are based mostly on first-hand development experiences and customer issues from working on one of such pioneering system for protecting web services (TransactionMinder). However, the ideas and design are intentionally kept general in nature so that they are applicable to other comparable systems as well.

What This Series Is Not About

First of all, there are plenty of materials on the market today covering theoretical aspects of WS-Security and how it can be used for protecting SOAP web services. For a theoretical foundation and general discussions about what WS-Security, XML Encryption, XML Signature, SAML, PKI, and other involved technologies are, one can use many available publications, both online and printed--see the Resources section below for some of these.

Of course, there will be explanations of the involved technologies and the purposes of different components in the appropriate sections where implementations are discussed, but they will assume an understanding of the subject matter at least at the fundamental level.

Secondly, many articles have been already published explaining:

  • The great promise of web services for automating business processes and linking heterogeneous systems.
  • The obstacles on this exciting road, the first and foremost of them being security, or, rather, the perceived lack thereof.

There is probably no need to reiterate here the importance of providing standards and tools for secure communication, nor to give one more account about the convoluted history behind the security standards in this area and complications in their development.

Ever since the inception of the commercial Internet, there have been attempts (some more successful than others) to form generic B2B automated processing chains. In such a setting, each participating web service will in turn be acting as a server and then as a client, when it issues a request to the next element of the chain. From a security standpoint, this means that it should either present its own credentials to the next service, or extract the user token(s) and pass them along, confirming that they are acceptable to it. In the world of SAML, these setups are aptly called Holder-of-Key (HK) and Sender-Vouches (SV) (see Section 5 of the "SAML Bindings and Profiles" PDF document), denoting the owner of the private key for the cryptographic signature securing the message. In Figure 1, communication between web services A and B corresponds to the HK scenario, and between B and C corresponds to SV.

Figure 1
Figure 1. Holder-of-Key and Sender-Vouches requests

Switching from the theoretical pathways and instead surveying the currently existing enterprise software landscape, the first notable thing to observe is the presence of access control systems designed specifically for web service protection (such as TransactionMinder or Management Point from Digital Evolution). These systems are generally aimed at fending off attacks lurking in the incoming SOAP messages, and are significantly more sophisticated than traditional firewalls, since, in addition to the standard firewall functionality, they include support for WS-Security and related technologies.

Therefore, in order to support forming an automated chain as described above, the requesting web service needs to appropriately prepare the outgoing messages so that they become acceptable to the access control system protecting the target web service.

This series will mostly concentrate on providing such a glue for linking web services sitting behind disparate access control systems. This task requires a slightly different subset of functionality from the traditional WS-Security implementation. The specifics will be reviewed in the Requirements section below, and a sample implementation will be developed in the follow-on articles.

What's Missing: The Problem

Obviously, enterprise-scale access control systems do not run in isolation. They are connected to back-end user directories and policy servers, which are used to obtain user credentials and attributes and make policy-based access control decisions.

Such systems will typically perform authentication and authorization tasks, based on the configured schemes, which can take a variety of credentials. Web-services-specific ones, among other things, include various WS-Security-based schemes, which extract the tokens, passed inside of the WS-Security headers, and use them for requestor's authentication. Additionally, as depicted in Figure 2, the access control system can modify incoming requests, inserting additional security headers, decorating them with specific authentication tokens, signatures, or decrypting the requests as needed.

Figure 2
Figure 2. The role of the access control system

However, what access control systems cannot do at the moment is assist the web services in automating the process of securing outgoing messages or simply extracting session information and credentials from the incoming requests. Such a job would require a special sophisticated proxy or gateway to modify the outgoing request before sending it out. Most of work in this area concentrates in hardware appliances (like the XS40 XML Security Gateway by DataPower), while the choice of software offerings, which provide rich proxy-style functionality, is quite limited.

Related Reading

Java vs. .NET Security
By Denis Piliptchouk

Therefore, developers of enterprise web services are forced to do a lot of hand-crafting to extract the required tokens and properly construct the outgoing messages, either performing primitive XML parsing, or making use of available generic toolkits for processing XML Signature and Encryption (available toolkits include: Apache's XML Security project, IBM's XML Security Suite), SAML (SourceID SAML 1.1 Toolkit), or WS-Security (Apache's WSS4J project, Phaos' WSSE Toolkit).

Since WS-Security encompasses a very broad range of technologies, its implementation necessarily relies on quite a few external SDKs. While a number of such toolkits is available today, numerous incompatibilities between them makes using all of them together a significant challenge in itself. To name a few potential problems: different sets of supported algorithms, incompatible certificate formats, conflicting JDK versions, and reliance on incompatible XML parsers.

Generality and richness of the standard itself leads to a very complex API, if such a general WS-Security SDK aims to support the complete specification. Complexity of its API usually requires additional development efforts to create homegrown simplified wrappers, which are useful for the specific needs that the organization's developers are trying to address.

Last, but not least, general off-the-shelf security SDKs usually are self-contained; i.e., they rely on their own stores and providers, and do not provide easy hooks for connecting to the existing back-end policy and user directories. Since enterprise developers need to rely on such repositories and connect their implementation to the existing infrastructure, oftentimes they have to incorporate multiple types of stores and formats in their systems, and create several layers of adapters to address their incompatibilities.

Intentions: Solution Requirements

As we are looking at a special case here--that of an enterprise web service developer behind an access control system--we do not need a full-blown SDK with complete standards implementation. Rather, a relatively light and simple API is needed that would help in addressing the existing gap in securing the automated processing chains.

Certain steps should have been taken care of by the front-gate access control system by the time the request reaches the target web service. In particular, message validation (its structure and completeness) should have occurred as one of the first activities, as well as signature verification and decryption of any encrypted content. So, at the input to our web service, we should have a valid SOAP message, with verified WS-Security headers (if present), and certain authentication tokens attached to them. The toolkit should assist web service developers ("Web Service B" in Figure 3) with extracting authentication tokens from the incoming request, creating new (case "Request B") WS-Security headers or altering the existing (case "Request A*") ones to address security policy's requirements of the target system ("Web Service C").

Figure 3
Figure 3. Chaining web services

More precisely, the following requirements can be identified for the intended WS-Security toolkit:

  • Existing access control systems use a great variety of back-end policy and user stores, and integration with this infrastructure is a necessary feature for any industry-grade application. While it is unrealistic to expect a custom toolkit to support all of these different sources and formats, it must expose reasonably simple generic interfaces that would allow plugging in (via configuration) different implementations for specific store providers.
  • Support for XML Signature and Encryption is generally added via a third-party SDK. As was outlined earlier, there are a number of implementations on the market, which are often mutually incompatible. Again, in order to avoid locking into a particular SDK vendor and version, the toolkit must expose necessary hooks to plug in wrappers for different implementations. The interfaces for these hooks must be defined at quite a low level to preserve broad compatibility with different SDK vendors. Fortunately, the scope of required cryptographic functionality is limited, since, as stated earlier, there is no need for performing signature validation, decryption, and a number of other standard cryptographic operations.
  • Support for generation of SAML tokens is included via hooks as well, by plugging in third-party SAML SDKs. The toolkit only concerns itself with properly inserting prepared assertions into the WS-Security headers, as specified in the SAML token profile (PDF).
  • The heterogeneous nature of web services dictates that the toolkit cannot be tied to a particular platform. If platform-specific items are required, they can be added by interfacing with the toolkit from the platform-specific layer using its public API.
  • In order to reduce the development effort, it is necessary to limit the choice of WS-Security security tokens supported by the toolkit. At the same time, design should not make the addition of new token types prohibitively complicated. In other words, this process should be abstracted as much as possible and designed with extensibility in mind.
  • Finally, as stated before, the toolkit should be relatively lightweight and expose simple external APIs, targeted to the specific tasks at hand. The last thing that is intended with development of this toolkit is burdening developers with another complicated API to learn.

Since the enterprise web services are already protected by an access control system, the following features are not required of the toolkit:

  • Authentication and authorization. This is not a part of the WS-Security standard anyway, but we can safely assume that all necessary authentication and/or session tokens have been added to the incoming request by the access control agent.
  • Message validation. Checks of WS-Security headers in the incoming messages for their structure and completeness are assumed to have been done prior to this stage, and messages with invalid content should have been rejected. The same applies to SAML assertions attached to the security headers.
  • Implementation of SAML-specific functionality. Since this series concentrates on WS-Security features, and SAML is just one of the supported tokens, the toolkit's implementation relies on the external providers to generate necessary assertions and implement SAML protocols.
  • XML Signature verification. All signatures should have been validated at the front gate, when the message was validated prior to letting it in.
  • XML Decryption. Any content that is supposed to be visible by the current web service should have been decrypted either before or right after signature verification.

Conclusion: Development Phases

Based on the general requirements for developing the toolkit, there will be several implementation phases, identified in the list below, each of them adding or extending a certain functional area:

  • General framework for creating WS-Security headers and inserting supported tokens.
  • Adding initial support for X.509, SAML, and Username tokens.
  • Adding supported tokens' extraction from the security headers of the incoming messages.
  • Adding XML Signature to the security headers of outgoing SOAP requests.
  • Supporting XML Encryption of outgoing SOAP requests.

Future installments of this series will build out the general framework and start adding features from the above list, discussing certain aspects of the appropriate standards along the way.

Resources

Denis Piliptchouk is a senior technical member of BEA's AquaLogic Enterprise Security group, participates in OASIS WSS and WS-I BSP standards committees, and regularly contributes to industry publications.


Return to ONJava.com.