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.
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:
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. 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.
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. 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.
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.
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. Chaining web services
More precisely, the following requirements can be identified for the intended WS-Security toolkit:
Since the enterprise web services are already protected by an access control system, the following features are not required of the toolkit:
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:
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.
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.
Copyright © 2009 O'Reilly Media, Inc.