Between Cloud, Mobility and the Enterprise is the API Middle Ground

Scott Morrison

Subscribe to Scott Morrison: eMailAlertsEmail Alerts
Get Scott Morrison via: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn

Related Topics: Apache Web Server Journal, SOA & WOA Magazine

Apache Web Server: Article

Policy-It's More Than Just Security - From just-in-time integration to Web services

Policy-It's More Than Just Security - From just-in-time integration to Web services

Business has long pursued the goal of making IT more of a strategic tool and less of a necessary evil. Organizations are constantly looking for easier, cheaper, and more logical ways to build applications and unite the silos of functionality they still depend on. One approach that has met with some success is the concept of just-in-time integration - a technique to combine new functionalities as quickly and cheaply as required, whether they reside inside an organization or outside of it (i.e., with a business partner).

From the architectural perspective, just-in-time integration is a cornerstone of service-oriented architecture (SOA). Under SOA, applications consist of aggregations of calls to services. Services are simply coarsely grained functions that are made available to invoking applications using a consistent semantic. They might encapsulate a well-defined unit of business logic, a legacy application, or an interface to a data gathering system. What a service does is not a concern of SOA - how it is made available is. One of the fundamental principles of SOA is the idea of loose coupling. Loosely coupled systems exhibit a flexibility such that a change effected in one component of the system does not break the rest of the system.

To achieve this, SOAs typically provide a mechanism to publish services and a means for consumers to discover and invoke them dynamically. Web services is an SOA - composed of technologies like SOAP, WSDL, and UDDI - that has the unique characteristic of being based on open standards and being independent of the deployment platform. This is in contrast to other SOAs, such as Sun's Jini, and alternative distributed application technologies, such as OMG's CORBA or Microsoft's COM+. But despite the media triumph of Web services, we still have a long way to go from this basic set of technologies to the end goal of just-in-time integration. This article will explore one of the most important issues in providing true loose coupling in a system of interconnected services.

WSDL Isn't Enough
A fundamental element in SOA is the interface, or contract. It defines the syntax of a service. It describes an interface by name, what data types the consumer must provide when calling the service, and what a consumer can expect to receive in return. The contract may also describe some service semantics using comments embedded in the description or through the logical grouping of functionality - such as methods or operations - into a common service unit. There is congruency between the SOA contract and the interface defined in languages like Java or C#, though unlike Java no semantic clues can be derived from static final variables, which are not exposed as part of a service definition.

The contract in Web services is the WSDL document. WSDL is a powerful technology, but it's important to recognize its limitations. WSDL describes an interface in two ways. It provides an abstract description of types and messages, but it also includes at least one concrete description that binds the abstract definition to a particular messaging technology. At present, this is almost exclusively HTTP SOAP messaging; however, WSDL, being XML, is reasonably extensible and so could similarly declare concrete bindings to other transport and marshalling mechanisms, such as proprietary binary protocols.

Since WSDL's limitations are not immediately obvious, let's consider a simple scenario familiar to everyone. Suppose you are a developer charged with building and deploying the corporate getQuote service (sorry). Disregarding, for a moment, the other important characteristics of SOA you might prefer to explore, focus instead on the everyday deployment: simple, point-to-point Web services. It would seem on first examination that WSDL provides everything we need to tie our client and quote server together. We have the service and operation names, message parts, data types, a return value - largely the same as we get with a Java or C# interface. Which brings us to an important question: Is WSDL no more than syntax - the morphology of the message needed to invoke the service remotely in an SOA? Is this all we need to achieve loose coupling in our architecture?

In some circumstances, the answer is clearly yes: we've all deployed and invoked getQuote with no more than this at our disposal. However, in doing so we may fall into a common trap, relying on WSDL for more than it was intended for. Suppose your next task is to deploy a secure getQuote using SSL. This is easy enough to accommodate in WSDL: a simple modification to the URL signifying the transport is https may be all that is necessary (in WSDL, the URL appears in the address element as the value of the location attribute). Unfortunately, your secure getQuote is destined to become a victim of its own success: over time, it increases in popularity to such an extent that it captures the notice of company officials. Shortly thereafter, a new corporate fiat comes down from the chief security officer (CSO) declaring all secure external communication is to be encrypted using 168-bit 3DES-EDE-CBC (Triple DES Encrypt-Decrypt-Encrypt Cipher Block Chaining - not a fast block encryption algorithm, but a very secure one).

SSL can accommodate this; however, WSDL cannot. This means you have to open up your code and start making changes. If you're lucky you might be able to simply tweak your infrastructure settings and let SSL negotiation run its natural course. If not, you might have to explore deep within your SOAP development kit and substitute an entirely new encryption layer (good luck…). Needless to say, these changes will break any client applications that rely exclusively on the original WSDL document for their interface and now have no way of discovering the updated security requirements. Our once loosely coupled system has become quite tightly and mysteriously bound.

However, we still aren't finished with getQuote. A further complication arises when this service is made available to a diverse group of service requesters, but subject to different security and reliability profiles. Those applications residing in the internal security domain must authenticate with the server using client-side certificates, which have been deployed recently as part of the corporate PKI initiative. IT is lagging in deploying certificates on external systems, so these systems should authenticate with username and password under the HTTP digest mechanism.

Herein lies a host of problems for the Web service provider. From the specification perspective, how do you convey these alternative requirements? From the development point of view, how do you implement these options into the service? From the maintenance point of view, how do you make subsequent changes in the service as new or different (but equally amorphous) requirements materialize, all without impacting existing service dependencies?

The service requester also faces considerable burdens: a vague yet complex set of security requirements defined by the provider, a set that is well beyond the capabilities, or indeed the intent, of WSDL to capture. Certainly, it eliminates any possibility of using a WSDL stub (or proxy) generator, so popular in modern IDEs. It is a situation that conspires to make it difficult to develop loosely coupled systems.

Formalized Policy Documents in SOAs
While this sounds like a contrived example, it actually illustrates a problem that's more common than you might think. Working within the context of a single process space, there is much we get free, so naturally there is much we take for granted. Security context (the state that declares who we are and what resources we can access), for example, is maintained by the OS and calls to methods don't cross process boundaries so there are no integrity or confidentiality issues to be considered. Linkers ensure that the code for a module is loaded and executed correctly and transparently. Distributed applications, in contrast, come with few of these luxuries and a whole host of new security risks that demand to be addressed.

The danger with simple Web services is that they lull us into overlooking the fundamental differences between a local and distributed application. In a way, they are too easy. Web services are brilliantly simple to deploy, and in delegating to existing and familiar infrastructure possess a resonance of completeness. But these solutions gloss over a more deep-seated problem: what we actually need is a mechanism to control how clients talk to services that is more rigorous, more expressive, than an IDL such as WSDL. What is required is finer control over the entire variant parameter space of the conversation - a difficult task when this is concealed in the murk of largely invariant code. This challenge begins with security-related parameters; however, it extends to a number of other equally critical parameters common to most robust distributed applications.

Consider the complexity of defining something as fundamental as the basic security model for a SOAP transaction. We could choose to delegate security to channel-based technologies (such as SSL or a VPN), or follow the newer trend espoused by the WS-Security initiative and decouple basic security from transport, only to absorb it in the message itself by signing and encrypting relevant message parts. How should our application perform authentication: present basic credentials; respond to a digest challenge; or use its client-side certificate? Should a consumer authenticate each message individually or maintain a security context, tracking this with session IDs or the continuity inherited from a persistent socket?

Historically, such questions have very often been answered implicitly through coding - a technique that rarely acknowledges or articulates its dependencies and underlying approach. Woe betide the poor developer charged with making a policy change to the security model hard coded deeply within the fabric of an application. More often than not, the fabric unravels.

What we would like in Web services - and by extension, SOA in general - is a way of declaring such policy directives independent from implementing the actual application code. Furthermore, the statements we make about policy should be dynamically bound to an application at runtime - a concept entirely consistent with the SOA directive of late binding. Need to assert a longer key length for encryption? Make the change to the policy declaration and it should be bound instantly to the running application. Policy, therefore, delivers on the promise of true loose coupling.

Clearly, WSDL today, with its focus on the syntax of the interface, isn't up to this. Fortunately, such an effort has been started, and a first proposal has been published as a framework of WS-Policy specifications.

Beyond Security
Policy suffers from being an overloaded word. Within the discipline of computer security, it has a particular multiplicity of meaning. To a CSO for example, policy is a set of corporate-specific security principles documented in a binder. This might follow the formal guidelines laid out in Internet RFCs 1244 and 2196, which describe how to develop a comprehensive security policy for an organization. As roles in an organization become more finely grained, so too does the scope and interpretation of policy. The firewall administrator laboring in the CSO's business unit probably thinks of policies in terms of concrete rules applied to TCP and UDP ports. The human resources department, on the other hand, defines policy regulating sick leave, carrying over vacation, which employees get a parking decal. Policy here often has nothing whatsoever to do with security issues.

With distributed computing, we very often see policy only in terms of security, missing its other nuances. Reliability is a good example of a characteristic of transmission that can be managed declaratively through policy. Large corporations like financial institutions spend vast sums of money on message-oriented middleware (MOM) to ensure that messages - and some of these are SOAP messages - are guaranteed to be delivered from one system to another, even if the ultimate destination is down when the message enters the system. Anyone who has built applications for these systems appreciates that MOM offers a tremendously powerful programming paradigm. It's inherently asynchronous, loosely coupled, and extremely scalable.

One of the beauties of MOM is how little a developer needs to know about the actual configuration of the infrastructure. Message time to live, routings through the network, retransmission periods - all of these parameters are configured by an administrator, as opposed to being hard coded into the application. An administrator can make radical changes to server deployment or alter the path a message follows in a WAN with no modification to client or server code. No developer needs to be engaged, and testing time can be greatly reduced.

MOM demonstrates the power of effective parameterization of distributed computing. Web services policy can bring similar profits. But rather than simply parameterizing the local operating characteristics of an application, as we so often do with property files or OS registries, it's about parameterizing all the characteristics of Web services transactions. Security clearly is the beginning, but reliability, transactional characteristics, Quality of Service (QoS) guarantees and expectations, and even message transformational parameters are all equally valid to decouple from an application and to make administrable.

Service Provider and Consumer Support
To support the SOA concept of runtime binding, policy must seamlessly integrate with existing Web services infrastructure, and be applicable across existing transactions. This is where the concept of a policy engine becomes attractive, as shown in Figure 1. A policy engine is a critical piece of Web services infrastructure that provides a point to administer, register, and apply policy to incoming Web services transactions.

Simple enforcement of policy is sufficient for some very basic security parameters that rely on unambiguous application of standards. For example, if policy only requires that transactions provide HTTP basic authentication credentials, it is something that's reasonable to delegate to the developer of the client. This is a clear requirement, easily written down and widely supported in existing SOAP development kits. In this role, the policy engine is little more than a simple application-level firewall.

However, the moment policy becomes more sophisticated and more dynamic, we have a problem. How do we effectively communicate complex policy requirements, which may continuously shift in response to changing business needs, to the client developer? How does the developer, using the Apache SOAP toolkit, accommodate a requirement for reliable message transmission, XML signature and canonicalization of the message envelope, and XML encryption of the body element? What happens when the OASIS WS-Security specification changes slightly, rendering our message traffic noncompliant?

Clearly, as policy grows in sophistication, the need for a Policy Application Point becomes critical. This can manifest as an agent application, shown in Figure 2, that can interpret policy documents, and dynamically apply policy assertions to Web services transactions at runtime. As policy changes, so too does decoration of a message in accordance with that policy. The agent can transform a message to be in compliance with the latest security specification; it also provides the mechanism for reliable messaging. This is the true promise of declarative policy. It realizes the dream of loose coupling by removing platform dependencies and assumptions from application code and putting the enforcement of policies into the hands of administrators, who can customize these in direct alignment with current business needs.

More Stories By Toufic Boubez

Toufic Boubez is the co-founder and CTO of Layer 7 Technologies. Prior to co-founding Layer 7 Technologies, he was the chief Web services architect for IBM's Software Group and drove their early XML and Web services strategies. Toufic co-authored the original UDDI API specification. He’s the co-editor of the W3C WS-Policy specification, and is a co-author of the WS-Trust, WS-SecureConversation, and WS-Federation specifications. Toufic is a sought-after presenter and has chaired XML and Web services conferences. In 2002, InfoWorld named Toufic to its “Ones to Watch” list. An author of many publications, one of his most recent books is "Building Web Services with Java: Making Sense of XML, SOAP, WSDL, and UDDI."

More Stories By Scott Morrison

K. Scott Morrison is the Chief Technology Officer and Chief Architect at Layer 7 Technologies, where he is leading a team developing the next generation of security infrastructure for cloud computing and SOA. An architect and developer of highly scalable, enterprise systems for over 20 years, Scott has extensive experience across industry sectors as diverse as health, travel and transportation, and financial services. He has been a Director of Architecture and Technology at Infowave Software, a leading maker of wireless security and acceleration software for mobile devices, and was a senior architect at IBM. Before shifting to the private sector, Scott was with the world-renowned medical research program of the University of British Columbia, studying neurodegenerative disorders using medical imaging technology.

Scott is a dynamic, entertaining and highly sought-after speaker. His quotes appear regularly in the media, from the New York Times, to the Huffington Post and the Register. Scott has published over 50 book chapters, magazine articles, and papers in medical, physics, and engineering journals. His work has been acknowledged in the New England Journal of Medicine, and he has published in journals as diverse as the IEEE Transactions on Nuclear Science, the Journal of Cerebral Blood Flow, and Neurology. He is the co-author of the graduate text Cloud Computing, Principles, Systems and Applications published by Springer, and is on the editorial board of Springer’s new Journal of Cloud Computing Advances, Systems and Applications (JoCCASA). He co-authored both Java Web Services Unleashed and Professional JMS. Scott is an editor of the WS-I Basic Security Profile (BSP), and is co-author of the original WS-Federation specification. He is a recent co-author of the Cloud Security Alliance’s Security Guidance for Critical Areas of Focus in Cloud Computing, and an author of that organization’s Top Threats to Cloud Computing research. Scott was recently a featured speaker for the Privacy Commission of Canada’s public consultation into the privacy implications of cloud computing. He has even lent his expertise to the film and television industry, consulting on a number of features including the X-Files. Scott’s current interests are in cloud computing, Web services security, enterprise architecture and secure mobile computing—and of course, his wife and two great kids.

Layer 7 Technologies: http://www.layer7tech.com
Scott's linkedIn profile.
Twitter: @KScottMorrison
Syscon blog: http://scottmorrison.sys-con.com

More Stories By Maryann Hondo

Maryann Hondo is the security architect for emerging technology at IBM, concentrating on XML security. She is one of the coauthors of the WS-Security, Policy, Trust and Secure Conversation specifications announced by IBM and other business partners. Before joining the emerging technology group she managed the IBM Tivoli Jonah team (IETF PKIX reference implementation) and was security architect for Lotus e-Suite participating in the development of Java Security (JAAS).

Comments (1)

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.