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 and its companion Practice (Part 1) describe 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, briefly describes its history, and 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 (WSSM) under development within OASIS.

Definition of a Web Services Security Model

Nowhere is this SOSA rethinking of traditional security architectures (e.g., isolation, perimeter defenses, centralization) more evident than in the evolving WSSM. Although Web services are part of the security problem since they represent immature technology for enabling system-to-system interoperation across boundaries, they are also part of the solution, because they can be used to implement a solution to the security issues raised by this type of interoperation. In this way, Web services are just like the Internet - creating security challenges and enabling their solution. For example, despite the fact that TCP/IP is unsecured, it nevertheless provides the foundation for Web single-sign-on solutions. The key is to build up a secure infrastructure out of partially secure layers.

A number of vendors are driving the effort to define the WSSM, which embodies the SOSA outlined above (see Figure 1). The various standards that define the WSSM can be roughly organized into three subarchitectures (see Figure 2):

• Trusted communication: SOAP, WS-Security, WS-SecureConversation
• Trusted service: WS-Policy, WS-PolicyAssertions, WS-PolicyAttachment, WS-SecurityPolicy,
• WS-Authorization, WS-Privacy (Note: WS-Authorization and WS-Privacy are not yet published)
• Trusted Web: WS-Trust, WS-Federation

Since Web services are based on a model of SOAP-message-style invocation of a WSDL service interface, the first two subarchitectures - trusted communication and trusted service - are defined as extensions of SOAP and WSDL to enable the exchange of security claims and policies as part of the invocation of a Web service. The third subarchitecture is composed of a set of WSDL interfaces defining a “security token service,” which creates a trusted Web enabling federated trust.

Trusted Communication

The WS-Security standard defines a trusted message-spanning layer as follows: WS-Security is flexible and is designed to be used as the basis for the construction of a wide variety of security models including PKI, Kerberos, and SSL. Specifically WS-Security provides support for multiple security tokens, multiple trust domains, multiple signature formats, and multiple encryption technologies.

WS-Security only defines an extensible message header model for applying existing digital signature, encryption, and security token mechanisms to the individual elements in a SOAP envelope (e.g., header and body blocks), so the recipient can trust the contents of the message and its sender. (OASIS has more accurately renamed its current revision of WS-Security “SOAP Message Security.”) The WS-Security standard notes, “This specification is intended to provide a flexible set of mechanisms that can be used to construct a range of security protocols; in other words, this specification intentionally does not describe explicit fixed security protocols.” WS-SecureConversation simply enables two endpoints to reuse a shared security context for a message conversation consisting of multiple SOAP message exchanges using a series of derived keys to increase security.

Trusted Service

The WSSM policy-based standards enable the creation of extensible policy definitions and their attachment to Web services interfaces. The following standards define this policy model:

• WS-Policy: Defines basic policy, policy statement, and policy assertion models
• WS-PolicyAssertions: Defines a few generic policy assertions
• WS-Policy Attachment: Defines how to associate a policy with a service, either by directly embedding it in the WSDL definition or by indirectly associating it through UDDI (Universal Description, Discovery and Integration)
• WS-SecurityPolicy: Defines security policy assertions corresponding to security claims defined by
• WS-Security: message integrity assertion, message confidentiality assertion, and message security token assertion

WS-Policy is an extensible model for expressing all types of domain-specific policy models: transport-level security, resource usage policy, and even end-to-end business-process-level policy. Of course, the only policy assertions standardized so far are those defined in WS-SecurityPolicy and WS-PolicyAssertions. WS-Policy is also able to incorporate other policy models such as SAML and XACML.

Trusted Web

Although the trusted communication and trusted service subarchitectures enable a service consumer and provider to directly interoperate in a secure and trusted manner, both assume that the same underlying security technology (e.g., identical username/password mechanisms) is used at both endpoints. Furthermore, they assume that both endpoints are encompassed by a single “sphere of trust” (sometimes referred to as a “trust domain”); for example, both sites trust the same certificate authority. This means that these specifications alone are insufficient to define how to send a message from one sphere of trust using one kind of key technology (e.g., Kerberos) to a different sphere of trust using a different key technology (e.g., PKI). This type of federated end-to-end security interaction will be enabled by the trusted Web.

To enable this federated end-to-end interaction requires the specification of a trust authority that acts as an intermediary (a.k.a. broker or gateway) between spheres of trust. This intermediary then brokers or gateways between two spheres of trust by transforming security tokens in one sphere of trust into security tokens with an equivalent degree of trust in the other sphere of trust.

The First Step: WS-Trust

Although significant portions of the WSSM are still unpublished (e.g., WS-Federation, WS-Privacy), WS-Trust takes the first step by conceptually defining such an intermediary, called a Security Token Service (STS - see Figure 1). The WS-Trust standard notes:

[An STS] is a Web service that issues security tokens (see WS-Security). That is, it makes assertions based on evidence that it trusts, to whoever trusts it. To communicate trust, a service requires proof, such as a security token or set of security tokens, and issues a security token with its own trust statement (note that for some security token formats this can just be a re-issuance or cosignature).

As its name implies, an STS simply issues, validates, and exchanges various types of security tokens in response to requests. WS-Trust defines several WSDL interfaces for requesting and receiving such security tokens.

An STS is very much like a PKI certificate authority (CA). However, it goes beyond the traditional concept of a CA in two important ways:

• The STS issues all types of tokens (e.g., authorizations, attributes, roles), not just identity tokens. We note that XML tokens such as SAML and XrML (Extensible rights Markup Language) emphasize claims such as attributes, roles, and authorizations, in addition to mere identity claims.
• The STS does not simply issue and validate tokens - it exchanges them. The key to an STS’s brokering role in a federated trusted Web is its ability to exchange one type of token (e.g., an X.509 certificate) for another (e.g., a Kerberos ticket). Of course, to carry out such an exchange, an STS must be trusted to issue certain types of tokens, and it must trust other types of tokens issued by other STSs.

For example, imagine an analyst registering for a trade show. The analyst requests an attendee badge at the registration desk (the STS) by providing her driver’s license, passport, or other government-issued photo IDs (i.e., external identity tokens) and a business card showing that she is indeed an analyst (i.e., an external role token). The registration desk issues an attendee badge to the analyst (i.e., an internal identity and role token) with colors and labels indicating claims regarding the analyst’s role (versus roles such as press, exhibitor, or speaker), which enables access to the sessions and the show floor. At each session room (i.e., service), the badge is checked (i.e., a policy enforcement point) to ensure that the analyst’s role is authorized to attend sessions. In this example, the registration desk is federating between the external business and governmental spheres of trust and the internal sphere of trust of the show.

Therefore, the role of the STS is to bridge existing isolated security islands into federated security island chains through the exchange of diverse types of security tokens. These security islands could be a customer and its suppliers, or they could be a set of business units formed by a series of mergers and acquisitions. Each island would maintain its own set of interior security protocols and administration, but each would also establish a set of border security protocols and administration, which determines the other islands in the island chain it trusts and in what ways it trusts them.

This type of federation can be viewed as a wide-area network (WAN) that links local-area networks (LANs) via gateway routers. Kerberos is like a security LAN - deployed primarily within a single administrative domain. Enterprise PKI via a corporate certificate authority is another security LAN. STSs then act as WAN gateway routers federating these two LANs. It is no coincidence that such distinctions sound similar to the Internet border gateway protocol (BGP) versus the interior gateway protocol (IGP) distinction used in routing packets across the autonomous systems that make up the Internet. The same conceptual design issues concerning federation are going on in both cases.

In the case of routing packets, the concern is how to create a unified end-to-end routing path that dynamically spans independently routed networks. In the case of dynamically federating trust, the concern is how to create a unified end-to-end chain of trust that spans independently secured networks. Therefore, the WSSM reinforces the view that end-to-end security is a network routing concept. Just as the Internet enables diverse data communications networks to interoperate via common packet routers, and Web services enable diverse XML-processing networks to interoperate via common SOAP intermediaries, the WSSM enables diverse trust-enforcement domains to interoperate via common token routers (a.k.a. STSs). This enables a trusted business services Web to be layered over the Internet’s trusted communications Web.

However, just as a network of routers must be managed by the Internet’s management network to provide the transparent Internet to users, so too the network of STSs must be managed to provide the transparent trusted business services Web. We call this network of STSs the trusted Web. And just as the Internet’s management network is composed of distinct functional networks, such as the network of DNS (Domain Name System ) servers providing host name services, or the network of SNMP (Simple Network Management Protocol ) servers providing management services, the trusted Web may be composed of distinct sets of STSs, each offering a different trust-enabling service (e.g., authentication servers enabling federated identity, authorization servers enabling federated authorization).

The Road Ahead: Filling in the WSSM

Although WS-Trust provides a detailed glimpse into the basic architecture of the trusted Web, it gives no insight into the federated administration issues raised by this type of an architecture. For example, WS-Trust leaves completely open the complex issue of trust delegation topologies among STSs. In fact, WS-Trust refers to several possible delegation models: fixed trust roots, trust hierarchies, and authentication service. Ensuring that the WSSM is general enough to accommodate all such topologies is good design, but a concrete implementation of the standard ultimately requires that choices be made. Presumably, WS-Federation will provide this type of concrete guidance.

There is also the entire set of issues involved in managing the comprehensive life cycle spanning the components that make up the WSSM (e.g., the STSs, the end-policy attachments, the underlying security mechanisms). For example, currently there is no standard for discovering services that require security management, or for services that can provide such management. However, the draft specification, WS-Management, is expected to deal with some of these issues in a way that is compatible with UDDI’s role as the Universal Description, Discovery and Integration of Web Services. At the very least, the WSSM must define a standard for provisioning security tokens and policies across STS intermediaries and Web services endpoints in much the same way that identity management provisions identities across multiple repositories. Currently, the OASIS SPML (Service Provisioning Markup Language) is the leading standard addressing such issues and is expected to be used in support of the WSSM.

Furthermore, the WSSM needs a standard mechanism for managing the “soft state” of distributed policies and tokens. Any globally scalable distributed system must cache a certain amount of metadata within local administrative domains. Thus, policy changes in one part of the federated security network may not be propagated to other parts of the network immediately. Accordingly, there must be some mechanism for ensuring the eventual consistency of such information, even in the face of occasional disconnects among regions (a.k.a. network partitions). DNS is perhaps the paradigm example of an architecture for dealing with this issue.

Engineering a highly consistent and available implementation of WSSM that can tolerate sporadic network partitioning will be a task left to vendor competition. An interesting approach to formalizing such an architecture is BASE (basically available, soft-state, eventual consistency), an alternative to traditional ACID approaches to distributed consistency that are based on the concept of continually attempting to recover consistency instead of simply preventing inconsistency.

A final missing piece of the puzzle is a well-defined model for end-to-end audit, logging, and reporting of distributed service requests. Given that WSSM enables attribute-based authorization, a single identity token may not be used end-to-end. Accordingly, it is essential that an authorization decision be traceable, retroactively, to the true identity of the entity accessing the service. Again, the identity management model and its interaction with identity infrastructure can serve as one model.

One way to enable this type of end-to-end auditability is to include the business-level identifying metadata in each SOAP header so that each SOAP agent (intermediary) can capture that metadata in its audit logs. Then tracing identity end-to-end would consist of tracing through each SOAP node’s audit log to discover each identity transformation (e.g., from John Doe to Yale student). Again, such traceability/auditability capabilities will be where vendors differentiate their implementations of the WSSM, though interoperability standards may ensure that each vendor can coordinate auditing responsibility across administrative domains.

Comparison to Traditional Security Architectures

Given that the WSSM is a service-oriented security architecture, it is explicitly designed with traditional security architectures in mind. In fact, the WSSM is an attempt to generalize the essential features of the mainstream security architectures so that interoperability among them can be provided. The uniqueness of the WSSM is this essential focus on interoperability across diverse security architectures. It does not define any concrete signature or encryption mechanisms because it expects to leverage existing ones. And although the WSSM does define some of its own security policy assertions and security token claims, it is designed to primarily leverage other token languages, such as SAML and XrML.

As previously discussed, because the WSSM is an SOSA - focused solely on federated interoperability - it is not a panacea. It does not address any of the challenges facing existing security mechanisms (e.g., manageability, performance, reliability) other than interoperability. For example, if the WSSM is used to interoperate between a single sign-on (SSO) product in Organization A and an SSO product in Organization B, the WSSM will do nothing to address the complexity of managing either SSO product. In this regard, the WSSM is no different from the paradigm service-oriented architecture - the Internet. Using the Internet to interoperate between two LANs does nothing to address each LAN’s manageability, performance, or reliability. Like the Internet architecture, the WSSM is devoted to solving one focused but vital challenge: federated interoperability. Indeed, WSSM is more of a management integration model than a management implementation model.

Some security standards take a related generic application programming interface (GAPI) approach to interoperability; for example, CAPI (Microsoft’s Crypto API), CDSA (Common Data Security Architecture), GSS (Generic Security Services), and GAA (Generic Authorization and Access Control). Each of these offers some type of standard GAPI that can be bound to a set of diverse drivers that implement the API. Although this generic driver approach has been proven by the success of ODBC and device drivers (e.g., printers, video cards), it actually only provides a mechanism for portability, not federated interoperability. Although a GAPI makes the underlying service implementation transparent to the application developer, it enables binding to only a single underlying service implementation at a time, not a federated network of diverse service implementations. For example, ODBC enables a client application to bind to any one of a set of diverse databases, but it does not enable all of the diverse databases to be used as one federated database (e.g., joining across the databases).

The WSSM is less concerned with a universal GAPI, though it is not incompatible with any of them. It is primarily concerned with a universal set of identifiers, formats, and protocols (IFaPs) for interoperating among diverse security domains. Therefore, the WSSM is more like the Internet-routing IFaPs, and GAPIs are more like dynamically “bindable” TCP/IP stacks for laptops, which can be bound to a dialup, LAN, or Wi-Fi connection. Other security standards enable federated administration (e.g., Kerberos realms, Active Directory forests, cross-certifying PKI CAs), but each requires that all administrative domains implement the same technology (e.g., all running Kerberos, all running PKI). The WSSM, on the other hand, does not specify any unique security technology. It is simply defined in terms of how it binds to existing standards.

Two competing standards that attempt to deal with not only federated administration but also federated identity across diverse identity services are the Liberty Alliance and Microsoft’s Passport. Microsoft has already announced that future versions of Passport will be based on the WSSM. Thus, the only issue is whether Liberty Alliance adopters will adopt the WSSM as well. Given that the Liberty Alliance is working closely with OASIS on SAML and other aspects of the Liberty architecture, and given that key standards underlying the WSSM have been turned over to the OASIS Web Services Security Technical Committee, we may see eventual convergence of the two standards under the umbrella of the WSSM.

The Impact on Security Vendors and Markets

As with IP, Web, and other interoperability standards (e.g., SCSI), once interoperability ensures that all products are roughly identical functionally, this leads to rapid commoditization of the underlying technology components. One can see this in the IP network component market, the Web server and browser markets, and even the storage-area network/small computer system interface (SAN/SCSI) storage market. However, in this type of commoditizing market, vendors shift the competition from the increasingly more generic components to focus on unique solutions for dealing with the complexity that inevitably arises when large numbers of commodity components are federated to provide a solution. Therefore, vendor solutions shift to focus on ease of deployment, quality of service, and ease of management.

Accordingly, even if the WSSM were to completely standardize interoperable secure Web services across organizational boundaries and across commoditized security mechanisms, this would simply lead to an upsurge in products and services for managing the life cycle of the commodity components constituting the WSSM. Vendors well positioned to benefit from the commoditizing interoperability enabled by the WSSM are those that are already grappling with the management issues surrounding complex and diverse security architectures.

Conclusion

The capabilities for interoperability and integration provided by the Internet, the Web, and Web services are enabling evolution of the service economy toward increasingly more federated business models on a global scale. Yet 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. The technology of these SOSA concepts will be realized by the evolving Web Services Security model.

Business Impact: 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, businesses must first trust strategic vendors and partners to apply this technology to specific business relationships.

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

META Group originally published this article on 7 October 2003.