Industrial IoT Authors: Pat Romanski, William Schmarzo, Elizabeth White, Stackify Blog, Yeshim Deniz

Related Topics: Industrial IoT

Industrial IoT: 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.

IoT & Smart Cities Stories
Moroccanoil®, the global leader in oil-infused beauty, is thrilled to announce the NEW Moroccanoil Color Depositing Masks, a collection of dual-benefit hair masks that deposit pure pigments while providing the treatment benefits of a deep conditioning mask. The collection consists of seven curated shades for commitment-free, beautifully-colored hair that looks and feels healthy.
The textured-hair category is inarguably the hottest in the haircare space today. This has been driven by the proliferation of founder brands started by curly and coily consumers and savvy consumers who increasingly want products specifically for their texture type. This trend is underscored by the latest insights from NaturallyCurly's 2018 TextureTrends report, released today. According to the 2018 TextureTrends Report, more than 80 percent of women with curly and coily hair say they purcha...
The textured-hair category is inarguably the hottest in the haircare space today. This has been driven by the proliferation of founder brands started by curly and coily consumers and savvy consumers who increasingly want products specifically for their texture type. This trend is underscored by the latest insights from NaturallyCurly's 2018 TextureTrends report, released today. According to the 2018 TextureTrends Report, more than 80 percent of women with curly and coily hair say they purcha...
We all love the many benefits of natural plant oils, used as a deap treatment before shampooing, at home or at the beach, but is there an all-in-one solution for everyday intensive nutrition and modern styling?I am passionate about the benefits of natural extracts with tried-and-tested results, which I have used to develop my own brand (lemon for its acid ph, wheat germ for its fortifying action…). I wanted a product which combined caring and styling effects, and which could be used after shampo...
The platform combines the strengths of Singtel's extensive, intelligent network capabilities with Microsoft's cloud expertise to create a unique solution that sets new standards for IoT applications," said Mr Diomedes Kastanis, Head of IoT at Singtel. "Our solution provides speed, transparency and flexibility, paving the way for a more pervasive use of IoT to accelerate enterprises' digitalisation efforts. AI-powered intelligent connectivity over Microsoft Azure will be the fastest connected pat...
There are many examples of disruption in consumer space – Uber disrupting the cab industry, Airbnb disrupting the hospitality industry and so on; but have you wondered who is disrupting support and operations? AISERA helps make businesses and customers successful by offering consumer-like user experience for support and operations. We have built the world’s first AI-driven IT / HR / Cloud / Customer Support and Operations solution.
Codete accelerates their clients growth through technological expertise and experience. Codite team works with organizations to meet the challenges that digitalization presents. Their clients include digital start-ups as well as established enterprises in the IT industry. To stay competitive in a highly innovative IT industry, strong R&D departments and bold spin-off initiatives is a must. Codete Data Science and Software Architects teams help corporate clients to stay up to date with the mod...
At CloudEXPO Silicon Valley, June 24-26, 2019, Digital Transformation (DX) is a major focus with expanded DevOpsSUMMIT and FinTechEXPO programs within the DXWorldEXPO agenda. Successful transformation requires a laser focus on being data-driven and on using all the tools available that enable transformation if they plan to survive over the long term. A total of 88% of Fortune 500 companies from a generation ago are now out of business. Only 12% still survive. Similar percentages are found throug...
Druva is the global leader in Cloud Data Protection and Management, delivering the industry's first data management-as-a-service solution that aggregates data from endpoints, servers and cloud applications and leverages the public cloud to offer a single pane of glass to enable data protection, governance and intelligence-dramatically increasing the availability and visibility of business critical information, while reducing the risk, cost and complexity of managing and protecting it. Druva's...
BMC has unmatched experience in IT management, supporting 92 of the Forbes Global 100, and earning recognition as an ITSM Gartner Magic Quadrant Leader for five years running. Our solutions offer speed, agility, and efficiency to tackle business challenges in the areas of service management, automation, operations, and the mainframe.