Service-Oriented Security Architecture: Part 1

For Web services to succeed in extending the remarkably successful "document" Web into a "trusted business services" Web that reliably spans the globe, designers must apply service-oriented security architecture concepts to architect a new trust management Web that can be federated across administrative domains and spheres of trust. The goal is not to replace the diverse security infrastructures already deployed, but to enable them to interoperate end-to-end.

META Trend: Initially deployed in 2002/03 as little more than an Internet-based set of integration and interoperability standards (XML, WSDL, UDDI), Web services will displace component-oriented distributed computing paradigms (J2EE, CORBA, COM+) with a more network-based, service-oriented architecture by 2010. Web services will provide an XML-based, metadata-driven agile infrastructure of composable services that extend, simplify, and reunite the Web into the "xWeb," enabling the integration and unification of content, applications, and process across platforms.

Service-oriented architecture (SOA) is a set of principles for designing extensible, federated, interoperable services. SOA principles can (and should) be applied not only to the services that compose a service-oriented business architecture, but also to the services that compose a service-oriented security architecture (SOSA), a service-oriented management architecture, etc. This META Practice describes an evolving SOSA based on the set of Web Services Security (WS Security)-related standards recently proposed by IBM and Microsoft, and now under development within the Organization for the Advancement of Structured Information Standards (OASIS). Part 1 defines the concept of SOA and briefly describes its history. It then applies the SOA to define the concept of an SOSA. Part 2 discusses the embodiment of these concepts in the Web Services Security model under development within OASIS.

As businesses evolve toward increased interdependence via the Internet and the Web, they face a steadily rising need for better coordination across organizational and business boundaries. Spanning the increasingly diverse technologies that must interoperate and the growing number of administrative and security domains that must cooperate to enable such coordination requires an interoperable, federated approach to security. To evolve existing corporate and regional communications networks into a global communications meta-network, the original designers of the Internet created the concept of a service-oriented architecture. An SOA federates existing technologies and policies by virtualizing their behavior into a unified service model.

For the emerging Web services architecture to succeed in extending the existing (and remarkably successful) document Web into a trusted business services Web that reliably spans the globe, its designers must apply SOA concepts to architect a new “trust management” Web that can be federated across administrative domains and spheres of trust. This Practice will discuss how the SOA shapes this evolving trust management Web and the emerging Web services security standards that define it, as well as how these standards complement existing security policies, processes, standards, and technologies.

Introduction

For several years, leveraging the Internet has been a key goal of many CIOs. Unquestionably, the Internet is changing the way we do business - indeed, the way we live our lives. Its value increases not only with every additional business or consumer that plugs into it (the so-called network effect), but also with every new technology that layers over it (e.g., the Web, e-mail, instant messaging, peer-to-peer file sharing, voice over IP) and every new technology that lies beneath it (e.g., optical and wireless networks). The Internet is becoming the universal way to span geographical, national, administrative, and even business and interpersonal boundaries, to globally integrate everyone in every way - data, voice, image, and video.

Of course, as the Internet’s business value increases, so does the need to protect the systems composing it and the business processes depending on it for protection from attack. This is especially true as fewer human intermediaries are directly in the business process loop, due to the increasingly direct system-to-system operation enabled by Web services. Some security challenges are magnified by the Internet (see Figure 1).

As a result, while use of the Internet has been a key goal, integration and security have topped the yearly lists of CIOs’ most difficult challenges. Integration, especially across the Internet, creates too much complexity and too little reliability - and trust - because too many diverse systems, accessed by too many external users, are being integrated across too many organizational boundaries, with too many incompatible integration and security services. Thus, the need to simplify and improve the Internet’s diverse existing integration, management, and security services is obvious. Given that the Internet’s fundamental purpose is to create the network effect by enabling integration across administrative and trust boundaries, traditional security architectures, which emphasize isolation, perimeter defenses, and centralization, must be rethought.

Although the need is obvious, the solution is subtle. We do not need yet another standalone security architecture. We need an architecture for interoperating across standalone security infrastructures. We can no longer afford (if we ever could) to rip and replace multiple existing security services with one monolithic service set. We must find a way to layer over existing technologies - without introducing yet another traditional security technology. Traditional security infrastructures are simply not designed to interoperate with alternative (much less competitive) security technologies - they are designed to replace them (e.g., replacing Distributed Computing Environments [DCE] with Kerberos).

The solution is to overlay existing security technologies with a service-oriented architecture. The essential goal of an SOA is to enable general-purpose interoperability among existing technologies and extensibility to future purposes and architectures. The goal is not to design any new functionality (e.g., a new encryption design, a new design for transmitting data across a medium, a new authentication method); instead, it is to enable interoperability across what is already available and to ensure such interoperability can be extended to include future innovations. Simply put, an SOA is an architecture, inspired by the Internet and the Web, for enabling extensible interoperability based on network concepts such as protocols and intermediaries.

However, even though an SOA may be a solution, it is not a panacea. Although it suggests a solution to the interoperability challenges raised by existing technologies, it does not solve any of their other problems (e.g., manageability, performance, ease of use).

The Invention of the Service-Oriented Architecture

The Internet’s protean nature is no accident. Its designers architected it essentially for interoperability and extensibility:

• “The top level goal for the DARPA Internet Architecture was to develop an effective technique for multiplexed utilization of existing interconnected networks.” - The Design Philosophy of the DARPA Internet Protocols [emphasis added]
• “Heterogeneity is inevitable and must be supported by design. Multiple types of hardware must be allowed for ... Multiple types of application protocol must be allowed for, ranging from the simplest such as remote login up to the most complex such as distributed databases. “- Architectural Principles of the Internet, RFC 1958

The designers did this by designing the Internet to be “an open network architecture that is both technology-independent and application blind”. This Internet concept has gone by many names over the years: catenet, meta-network, virtual network, network of networks, spanning layer, and now SOA. It is the Internet’s SOA that has been the key to its adaptability, cost-effectiveness, and efficiency (see Figure 2).

Thus, the Internet uses generic IFaPs (e.g., IP address, IP packet, TCP/IP protocols) to virtualize a diverse array of specific concrete communications services (e.g., Ethernet, Token Ring, Frame Relay, SONET, PSTN, Wi-Fi) into a single federated communications Web. The Internet’s meta-network approach of leveraging existing networks instead of replacing them is one of the primary reasons the Internet succeeded in creating a network effect that displaced all other proprietary wide-area networks.

An SOA is best visualized as an hourglass-shaped “spanning layer,” because a spanning layer resembles the narrow waist of an hourglass - enabling a wide variety of applications above and virtualizing a wide variety of technologies below (see Figure 3). The term “spanning layer” was coined by David D. Clark, the former chair of the Internet Activities Board, as noted in his paper, “Interoperation, Open Interfaces, and Protocol Architecture”:

Certain protocols are designed with the specific purpose of bridging differences at the lower layers, so that common agreements are not required there. Instead, the layer provides the definitions that permit translation to occur between a range of services or technologies used below. Thus, in somewhat abstract terms, at and above such a layer common standards contribute to interoperation, while below the layer translation is used. Such a layer is called a “spanning layer” ...

The Web extends the spanning-layer concept from the Internet’s communications layer to create an application-level spanning layer. Inspired by many of the design principles that shaped the Internet, Tim Berners-Lee based the Web’s SOA on just three fundamental IFaP standards:

• URL (identifier)
• HTML/MIME (format)
• HTTP (protocol)

The Web’s SOA has enabled it to achieve the network effect as well. Other examples embodying many of the SOA principles are federated networks such as e-mail (SMTP - Simple Mail Transport Protocol), physical mail, intermodal shipping, and ATM networks.

Evolving Beyond the Limits of the Web to Web Services

Although the Web’s IFaPs have proven to be amazingly technology-independent - spanning virtually every underlying technology, from J2EE and .Net to CICS and AS/400 - they have not proven to be equally “application blind.” Up until now, the Web has been primarily applied to integrate people with services via document-centric browsers - creating the document Web.

Web services extend the boundary-spanning integration capabilities of the document Web by using a fully service-oriented architecture to define a business services Web enabling simple, uniform, and direct integration among services across the Internet. But creating a basic Web services architecture is not enough. To achieve the ultimate goal of a trusted business services Web, traditional security architectures must be rethought to adapt to Web services’ SOA.

The Concept of a Service-Oriented Security Architecture

How then should security be redefined by an SOA to create a service-oriented security architecture reinforcing the network effect of the Internet, the Web, and Web services, instead of impeding it? The key is to ensure that the core standards (i.e., IFaPs) deliver the essential characteristics of an SOA (as shown in Figure 2).

With regard to the SOA’s federation requirement, traditional security services are where network services were when the Internet was invented 30 years ago - each new security standard still seeks to replace what is in place. But there is often little need for new security standards for the basic services (authentication, authorization, encryption, digital certificate, and digital signature), given the myriad standards that have already been deployed across organizations.

Instead, what is sorely needed is a security spanning layer that enables all of these existing security services to interoperate. This is the fundamental goal of the emerging XML and Web services security standards - not to replace the diverse security infrastructures already deployed, but to enable them to interoperate end-to-end. Of course, the goal is not to permanently embed existing security infrastructures, especially almost obsolete ones. Rather, the goal is to not require their immediate replacement in order to adopt the SOSA and instead leave the issue of their eventual replacement as a separate business issue.

What then should define the core IFaPs that shape the SOSA spanning layer? The answer is trust. The fundamental underpinning of any SOA is trust, as noted by OASIS WS Security (Core): “Trust is the characteristic that one entity is willing to rely upon a second entity to execute a set of actions and/or to make [a] set of assertions about a set of subjects and/or scopes.”

For a service consumer to delegate responsibility for executing a process to a service provider, a policy of trust must underlie that delegation. A consumer, for example, before delegating responsibility for holding her savings to a bank, must first trust the bank. Thus, the ultimate goal of an SOSA is to enable such trust by establishing and enforcing security policies defined by a trust model, without regard to specific enforcement mechanisms. Accordingly, the core IFaPs of an SOSA should be based not on any specific enforcement mechanism, but on a generic model of policy-based trust:

• Identifiers: For consumers and services
• Formats: For tokens and policies
• Protocols: For exchanging tokens and policies

In other words, the SOSA should be defined in terms of generic protocols for exchanging generic (token) claims offered by service consumers and generic policy rules regarding such claims enforced by service providers. The advantage of this approach is that, in a highly federated scenario, only these generic policy rules and token metadata need to be generically exchanged across diverse administrative domains, leaving such domains free to use different concrete policy and token mechanisms, such as Public Key Infrastructure (PKI), Active Directory, and Kerberos.

The interoperable formats of an SOSA should define a generic policy model, modularized into the following conceptual building blocks:

• Policy: A set of policy assertions.
• Policy assertion: A specific preference, requirement, capability, or other property. A more general and perhaps clearer definition of policy assertion is, “A rule that governs a choice in the behavior of a system”.
• Security token: A set of security claims. Security tokens can be either binary (e.g., X.509, Kerberos ticket) or XML (e.g., SAML, XrML). A certificate (e.g., X.509) or a ticket (e.g., Kerberos) is simply a signed security token. XML tokens can be signed as well; thus, certificates are also either binary or XML.
• Claim: A policy-relevant statement made by or about a subject accessing a service.

The interoperable protocols of an SOSA should define a generic process model, modularized into the following subprocesses:

• Generating and distributing service security policies via service definitions (e.g., WSDL) and service directories (e.g., UDDI)
• Generating and distributing security tokens
• Presenting tokens in messages and service requests
• Evaluating whether presented tokens meet required policies

Finally, the interoperable identifiers of an SOSA should define a generic reference model for subjects, resources, services, and policies. URLs fit this bill quite nicely.

Of course, these SOSA IFaPs must embody some concept of federation via intermediaries. Competing and complementary influences have produced roughly similar concepts of federation embodying roughly similar policy processing concepts. These concepts have been based on distinctions among the following types of intermediaries:

• Policy enforcement point: A service that enforces policy decisions, typically at the point of access (e.g., firewall, OS, application)
• Policy decision point: A service that applies tokens (claims) to policies to generate a policy decision
• Policy administration point: A service that generates policies
• Security token service (authority): A service that issues, validates, and exchanges tokens (claims)

Several standards embodying various aspects of this type of SOSA have been designed during the past several years (see Figure 4).

Conclusion
The capabilities for interoperability and integration provided by the Internet, the Web, and Web services are enabling the evolution of the service economy toward increasingly more federated business models on a global scale. However, one of the most significant drags on the pace of this evolution is the lack of a security architecture that enables trust relationships among business entities to be established and administered in a more standardized and more automated way.

Still, the ability of businesses to trust this technology will not be based on the generic technology alone. To bootstrap into trusting technology for delegating trust, business must first trust strategic vendors and partners to apply such technology to specific business relationships. These vendors will be trusted only when they have earned that trust by repeatedly delivering successful business solutions. Part of this trust should be based on the vendors’ mastery of the diverse technologies to be federated by the SOSA and its competence and capabilities in deploying, managing, and auditing such technologies. It is from this initial direct personal relationship of trust with a few key partners that the indirect automated Web of trust will be woven to span the globe.

Business Impact: The ability of businesses to trust such technology will not be based on the generic technology alone. To bootstrap into trusting technology for delegating trust, businesses must first trust strategic vendors and partners to apply this technology to specific business relationships.

Bottom Line: The fundamental goal of a service-oriented security architecture is not to replace the diverse security infrastructures already deployed, but to enable them to interoperate end-to-end. The technology of these SOSA concepts will be realized by the evolving Web Services Security model.

META Group originally published this article on 7 October 2003.