an introduction to the web services architecture and its specifications

8/9/2019 An Introduction to the Web Services Architecture and Its Specifications

1/41

Web Services Technical Articles

An Introduction to the Web ServicesArchitecture and Its Specifications

Version 2.0

October 2004

Authors

Luis Felipe CabreraChristopher KurtDon Box

Copyright Notice

2004 . All rights reserved.

Summary:This introduction to the Web services architecture describes the design principlesunderlying the architecture and foundational technologies for Web services. Features aredescribed and linked to the specifications that formally define them. This paper also servesas a reference guide to all the specifications in the architecture. (51 printed pages)

Status

The contents of this white paper reflect the features of the various Web servicesspecifications at revision levels current as of the publication date. As the Web servicesspecifications are refined and additional specifications are released, this paper will be

updated to reflect the most recent changes.

Contents

Introduction Message-Orientation Protocol Composability Autonomous Services Managed Transparency Protocol-Based IntegrationThe Web Services Architecture

Core Messaging

XML and the Infoset SOAP Message Exchange Patterns Transport Independence AddressingMetadata

Security

Message Integrity and Confidentiality Trust Based on Security Tokens Secure Sessions
http://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#intr_topic1http://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#intr_topic2http://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#intr_topic3http://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#intr_topic4http://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#intr_topic5http://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#intr_topic6http://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#introwsa-upd_topic6ahttp://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#intr_topic7http://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#intr_topic8http://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#intr_topic9http://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#intr_topic10http://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#intr_topic11http://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#intr_topic12http://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#intr_topic13http://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#intr_topic14http://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#intr_topic15http://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#intr_topic16http://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#intr_topic17http://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#intr_topic2http://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#intr_topic3http://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#intr_topic4http://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#intr_topic5http://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#intr_topic6http://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#introwsa-upd_topic6ahttp://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#intr_topic7http://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#intr_topic8http://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#intr_topic9http://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#intr_topic10http://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#intr_topic11http://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#intr_topic12http://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#intr_topic13http://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#intr_topic14http://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#intr_topic15http://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#intr_topic16http://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#intr_topic17http://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#intr_topic1


2/41

Security Policies System FederationsDiscovery Directories Dynamic DiscoveryAgreement Coordination Protocols Reliable Messaging and Transactions

Reliable Messaging Designated CoordinatorsEnumeration, Transfer, and Eventing Enumeration Transfer EventingManagement

Concluding RemarksAcknowledgements

Appendix A: Glossary

Appendix B: XML Infoset Information Items

Appendix C: Common Security Attacks

Appendix D: References

Core Specifications Web Services Specifications Interoperability Profiles Other Resources

Introduction

The Web has been a phenomenal success at enabling simple computer/human interactionsat Internet scale. The original HTTP [HTTP] and HTML [HTML] protocol stack used by today'sWeb browsers has proven to be a cost-effective way to project user interfaces onto a widearray of devices. A key factor in the success of HTTP and HTML was their relative simplicityboth HTTP and HTML are primarily text-based and can be implemented using a variety ofoperating systems and programming environments.

Web services take many of the ideas and principles of the Web and apply them tocomputer/computer interactions. Like the World Wide Web, Web services communicateusing a set of foundation protocols that share a common architecture and are meant to berealized in a variety of independently developed and deployed

systems. Like the World Wide Web, Web services protocols owe much to the text-based heritage ofthe Internet and are designed to layer as cleanly as possible without undue dependencieswithin the protocol stack.

An important area in which Web services differ from the World Wide Web is scope. HTTP and

HTML were designed around "read-mostly" interactive browsing of content that is oftenstatic, or at least highly cacheable. In contrast, the Web services architecture is designed forhighly dynamic program-to-program interactions. In the Web services architecture, manykinds of distributed systems may be implemented. Examples include synchronous andasynchronous messaging systems, distributed computational clusters, mobile-networkedsystems, grid systems, and peer-to-peer environments. The broad spectrum of requirementsin program-to-program interactions forces the Web services protocol stack to be much moregeneral purpose than the first Web protocols. However, like the Web, Web services rely on asmall number of specific protocols. We discuss these at more length later.
http://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#intr_topic18http://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#intr_topic19http://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#intr_topic20http://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#intr_topic21http://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#intr_topic22http://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#intr_topic23http://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#intr_topic24http://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#intr_topic25http://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#intr_topic26http://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#intr_topic27http://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#intr_topic28http://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#intr_topic29http://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#introwsa-upd_topic29ahttp://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#intr_topic30http://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#intr_topic31http://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#intr_topic32http://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#intr_topic33http://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#intr_topic34http://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#intr_topic35http://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#intr_topic36http://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#intr_topic37http://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#intr_topic38http://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#intr_topic39http://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#wsawhitepapermsdn040825_ref_httphttp://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#wsawhitepapermsdn040825_ref_htmlhttp://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#wsawhitepapermsdn040825_def_web_servicehttp://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#intr_topic18http://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#intr_topic19http://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#intr_topic20http://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#intr_topic21http://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#intr_topic22http://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#intr_topic23http://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#intr_topic24http://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#intr_topic25http://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#intr_topic26http://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#intr_topic27http://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#intr_topic28http://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#intr_topic29http://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#introwsa-upd_topic29ahttp://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#intr_topic30http://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#intr_topic31http://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#intr_topic32http://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#intr_topic33http://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#intr_topic34http://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#intr_topic35http://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#intr_topic36http://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#intr_topic37http://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#intr_topic38http://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#intr_topic39http://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#wsawhitepapermsdn040825_ref_httphttp://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#wsawhitepapermsdn040825_ref_htmlhttp://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#wsawhitepapermsdn040825_def_web_service


3/41

We envision that the next generation of mainstream applications will be based onautonomous Web services. The implications of autonomy are central to the architecture, andthey will be explored throughout this paper. The technical content of this paper describesthe infrastructure protocols defining the Web services architecture and a key conceptneeded to build autonomous distributed applicationsthe concept of contracts.

The core principles that have driven the design and implementation of the Web servicearchitecture protocols are as follows:

Message orientationusing only messages to communicate between services andrealizing that messages often have a life beyond a given transmission event.

Protocol composabilityavoiding monoliths through the use of infrastructure protocolbuilding blocks that may be used in nearly any combination.

Autonomous servicesallowing endpoints to be independently built, deployed,managed, versioned, and secured.

Managed transparencycontrolling which aspects of an endpoint are (and are not)visible to external services.

Protocol-based integrationrestricting cross-application coupling to wire artifactsonly.

The remainder of this section describes these principles in detail.

Message-Orientation

Web services communicate using messages. They place a significant emphasis on howindividual messages are formed and processed. Unlike RPC systems in which messages arestrictly subordinate to the local programming experience, the Web services architecture isbuilt with messages as the atomic unit of communication. This is true not only of the wireformat used for message exchanges (SOAP [SOAP]), but also for the descriptions of a givenWeb service (WSDL [WSDL]). Granted, some developers may choose to view a Web serviceusing the remote procedure call metaphor; however, this decision is local to that developer's

code and not visible on the wire.

Web services assume SOAP as the lowest layer in the protocol stack and isolates messagetransfer from transport details. Ideally, protocol-specific bindings do not leak into applicationsemantics. This approach provides a sound base for achieving service interoperabilityamong development platforms, and provides for richer communication patterns. Webservices have typically relied on HTTP as the underlying message transport. By leveragingthe open extensibility of HTTP POST, many Web services have been bootstrapped using off-the-shelf Web technologies. As more sophisticated applications of Web services emerge, theimportance of other transports becomes clear. For example, it is cumbersome, at best, toimplement full-duplex message exchanges over HTTP's strict request/reply discipline. Incontrast, sending SOAP messages over TCP [TCPIP] using a lightweight framing protocolallows any two-party message exchange pattern to be implemented trivially.

Web services may distribute the processing of a given message across multiple networknodes, each of which contributes some piece of functionality, such as access checks,content-based routing, or application-specific validation. This distributed processing modelimplies that a given message may need to traverse two or more message transports prior toarriving at the ultimate receiver. For that reason, much of the early protocol work in Webservices was focused on providing end-to-end secure and reliable message delivery overarbitrary transports. For the simplest deployments in a single trustdomain where a secure andreliable transport is available (e.g., TLS [TLS] over TCP or HTTP), more robust protocols such
http://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#wsawhitepapermsdn040825_def_messagehttp://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#wsawhitepapermsdn040825_def_servicehttp://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#wsawhitepapermsdn040825_ref_soaphttp://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#wsawhitepapermsdn040825_ref_wsdlhttp://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#wsawhitepapermsdn040825_ref_tcpiphttp://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#wsawhitepapermsdn040825_def_exchange_patternhttp://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#wsawhitepapermsdn040825_def_trust_domainhttp://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#wsawhitepapermsdn040825_def_domainhttp://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#wsawhitepapermsdn040825_ref_tlshttp://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#wsawhitepapermsdn040825_def_messagehttp://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#wsawhitepapermsdn040825_def_servicehttp://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#wsawhitepapermsdn040825_ref_soaphttp://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#wsawhitepapermsdn040825_ref_wsdlhttp://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#wsawhitepapermsdn040825_ref_tcpiphttp://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#wsawhitepapermsdn040825_def_exchange_patternhttp://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#wsawhitepapermsdn040825_def_trust_domainhttp://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#wsawhitepapermsdn040825_def_domainhttp://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#wsawhitepapermsdn040825_ref_tls


4/41

as WS-Security [WS-Security] or WS-ReliableMessaging [WS-RM] are optional. For richerdeployments, these latter protocols are essential.

Protocol Composability

Protocols are said to compose when they can be used either independently or in

combination. Numerous domain-specific communication protocols are effectively "silos" inwhich protocol designers find themselves coining new mechanisms for dealing with security,reliability, error reporting, etc. Given the broad applicability of Web services, this approachto defining an entire protocol for each vertical domain breaks when domains overlap andbecomes extremely costly in terms of both initial development and ongoing support costs.

To avoid these costs, the Web services protocol suite is designed as a family of composableprotocol building blocks. By design, each of the infrastructure protocols defines a fine-grained unit of functionality. For example, the basics of signing and sealing messagecontents is generic enough that it is specified once (in WS-Security) and then leveraged byvarious infrastructure protocols and application-level protocols.

Web service protocol composition is based on the modular architecture of SOAP. SOAP'sarchitecture anticipates the composition of infrastructure protocols through the use of aflexible header mechanism. One advantage of this approach is that the protocol surface areafor a particular application is based on the actual features used by that application. A givenprotocol imposes absolutely no cost to applications that do not use it. Software operating oncomputing devices of various scales can use the exact protocols they need, maximizing theapplicability of the architecture. A second advantage is that new protocols can be introducedat any time to complement the existing ones and extend functionality. The ability toinnovate is thus built-in to the architecture. The challenge of getting a coherent andcomprehensive view of the spectrum of available protocols is real. Addressing this challengeis the goal of this document.

Specification profiles are provided to define usage constraints and the best practices for useof these specifications in various combinations. More information on specific profiles isprovided in the

sectionon Interoperability Profiles, the WS-I Basic Security Profile, and the Device Profile for Webservices.

Autonomous Services

Web services are autonomous agents whose development, deployment, operation,management, and security all vary independently from those of the service's consumer. This"forced independence" has several important ramifications that permeate the architecture.

Service autonomy has deep implications on how versioning is implemented. As a service'simplementation evolves, changes in the universe of compatible consuming applications areinevitable. Having reasonable tools for managing these changes is critical to the correctoperation of Web service-based systems. At the most basic level, SOAP provides a protocolevolution model based on SOAP headers. SOAP headers are expected to be added orremoved to a given message format over the lifetime of a given protocol. As new headersare introduced, the upgrade policy is carried in the header itself. Headers that may be safelyignored are simply inserted into the message. Headers that cannot be safely ignored areannotated with a mustUnderstand attribute, indicating that their insertion is a breaking
http://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#wsawhitepapermsdn040825_ref_ws_securityhttp://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#wsawhitepapermsdn040825_ref_ws_rmhttp://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#wsawhitepapermsdn040825_def_protocol_compositionhttp://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#wsawhitepapermsdn040825_ref_ws_securityhttp://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#wsawhitepapermsdn040825_ref_ws_rmhttp://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#wsawhitepapermsdn040825_def_protocol_composition


5/41

change and that only recipients that recognize the header may process the message. Thisbasic model for extensibility is most visible in SOAP itself; however, it is mirrored in variousother Web service protocols, including WSDL. More importantly, this principle is used byWeb services to add new protocol functionality (e.g., security) to a single messaging format(SOAP). Ultimately, the primary feature of SOAP is extensibilitynew versions of SOAP arenot needed for each new protocol requirement.

The autonomous nature of services also requires a greater emphasis on explicitmanagement oftrust between applications. Because many services have network addressesthat are visible from the public Internet, a greater degree of care is needed to ensure thatmalicious agents cannot compromise the integrity of a service. Part of this care takes theform of stronger input validation, which often can be automated using various schemalanguages. A more interesting aspect of this increased focus on system integrity is the useof explicit trust models. A key feature of WS-Securitybased systems is that a givenmessage may contain multiple security tokens. Some of these tokens may correspond to useridentities orprincipals. Other tokens may correspond to rights that are granted to a particularuser or application, and can be cryptographically validated as part of a broader authorizationscheme.

Autonomous services must also maintain control over the resources they manage. Inparticular they need to recycle resources created by requests of services that will notinteract again. Resource reclamation policies are needed for all kinds of resources. A popularscheme is the use of leases as exemplified by subscriptions for event notification later in thispaper. Asynchronous messaging allows services to have complete local control over thescheduling of message processing. Services also have flexibility regarding messagetransmissions, connectivity management, and independent failure modes.

Finally, the autonomous nature of Web services invariably requires processes or systemsthat were at one time centralized to move to a federated model. This is true not only ofsecurity identities, but also of service directories and systems management as well. Thesenew systems have to operate well in the presence of unbounded message latencies,independent failure modes, and when services are intermittently connected to the network.

Managed Transparency

All implementation details are private to a service. The message-oriented faade that everyservice exposes provides ample insulation from the implementation choices made by aparticular service developer. This opacity is critical to service autonomy, and allowsflexibility of programming models, operating systems, and other implementation details. Italso allows the substitution of one service implementation for another. Ideally, as long asboth services respond to the same set of request messages with comparable results, therequestor is none the wiser that a different implementation of a service has been used.

Given the emphasis on autonomous services, it is somewhat ironic that Web services place a

great deal of emphasis on the transparency of implementation-specific information. Forexample, if a service were completely opaque, one could not tell whether the set of inputmessages accepted by Service A were similar to or different from those accepted by ServiceB. For this reason, services are expected to make their publicly visible aspects transparentto the outside world. This transparency is achieved through the use of contracts, machine-readable descriptions of the messages a service sends or receives, as well as the abstractcapabilities and requirements of the service.

Public service descriptions are essential for creating a rich ecosystem for tools andexecution environments, and play an important part in achieving interoperability between
http://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#wsawhitepapermsdn040825_def_trusthttp://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#wsawhitepapermsdn040825_def_security_tokenhttp://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#wsawhitepapermsdn040825_def_principalhttp://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#wsawhitepapermsdn040825_def_authorizationhttp://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#wsawhitepapermsdn040825_def_trusthttp://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#wsawhitepapermsdn040825_def_security_tokenhttp://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#wsawhitepapermsdn040825_def_principalhttp://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#wsawhitepapermsdn040825_def_authorization


6/41

heterogeneous systems. Development tools rely on service descriptions in order to createprogrammer-friendly language bindings for the messages a service accepts or sends.Deployment tools rely on service descriptions to wire up a deployed service to one or morepublicly visible endpoint addresses. Management tools rely on service descriptions to trackwhether a given service is operating within its expected collection of input and outputmessages. Finally, the runtime binding of a requestor to a given service can take advantage

of service descriptions to ensure that a compatible service is selected during the normalexecution of an application.

Managed transparency not only applies to descriptions of services, but also to the messagesthemselves. Unlike monolithic protocols of the past, SOAP and WS-Security together providea flexible security layer in which different parts of a message may have distinct securitycharacteristics. This means that the sender may elect to leave some aspects of the messagecompletely transparent and visible to all potential readers, while encrypting other parts ofthe message for only a trusted set of readers to see. In the general case, each message partmay be encrypted for a distinct set of readers. Those message parts that are not encryptedcan be signed to protect them against tampering.

Protocol-Based Integration

Application integration is simplified when message-based protocols are used for allcommunication. By building a self-contained system for description and messaging that isdevoid of programming language or operating system details, Web services have shown thatit is possible for applications running in truly disparate environments to communicatesecurely and reliably. The only way this could be made to work was to assume no shared OS,no shared virtual machine, and no shared programming language or abstraction.Independence from underlying implementation technology is the key to Web servicesinteroperability. Web services have influenced many aspects of software development. Theprimary contribution of Web services has been the emphasis on protocol-based softwareintegration.

The influence of protocol-based integration on the industry at large can be seen in the

increasing emphasis on service-oriented architectures. Both Web services and serviceorientation owe much to the ideas of component software, distributed objects, and message-oriented middleware. Information encapsulation and polymorphism have been adopted fromobject orientation, and mandatory use of interfaces and the use of runtime metadata havebeen adopted from component software. Distributed objects contributed notions of contextthat flows among entities and broker-based bindings. Of course, message-orientedmiddleware brought the use of queues, relays. and explicit message passing.

Web services communicate using a concrete set of protocols based on a commonarchitecture with SOAP as its foundation. In contrast, service orientation is an abstract set ofideas and concepts that can be manifested in any number of ways (much like object-orientation before it).

Web services can be used to implement a service-oriented system, but service-orientationdoes not necessitate the use of Web service protocols, nor does the use of Web serviceprotocols ensure that the overall system design is service-oriented. That stated, Microsoft isinvesting heavily in making the combination of Web services and service-orientation animportant part of Windows.

The broad adoption of service-oriented architectures is accelerating as a result of severalunderlying factors. Network infrastructure is now pervasive, enabling cost-effectivecomputer-to-computer communication. Systems built from Web services provide a software


7/41

development approach that enables legacy applications to be incorporated in incrementalsteps. Finally, service autonomy provides for more robust applications.

This introduction has presented the main enablers, motivators, requirements, and principlesthat guide the Web services architecture. The rest of the paper presents the coretechnologies that underlie the architecture, followed by a tour through the collection of

specifications that define Web services.

The Web Services Architecture

The rest of this paper provides a detailed introduction to the Web services architecture. Wereview the Web services components and mechanisms they build upon, in support of thearchitecture's design. Each feature of the architecture is presented in the context of thespecifications where it is defined.

Core Messaging

This section presents core specifications used to formulate messages in the Web servicesarchitecture: XML, SOAP, and WS-Addressing [WS-Addressing]. Web services rely on XML forthe basic underlying data model, SOAP for the message processing and data model, and WS-Addressing for addressing services and identifying messages independent of transport.

XML and the Infoset

For all messaging systems, the selection of the unit of information transfer is an importantdecision. Simply put, a common understanding of exactly what constitutes a message isrequired. In Web services, a message is an XML document information item as defined bythe XML Information Set, or Infoset, [XML-Infoset]. The Infoset is an abstract data model thatis compatible with the text-based XML 1.0 [XML-10] and is the foundation of all modern XMLspecifications (XML Schema [XML-Schema], XML Query [XML-Query], and XSLT 2.0 [XSLT-20]).

By basing the Web services architecture on the XML Infoset rather than on a specificrepresentation format, the architecture and core protocol components are compatible withalternative encodings.

The Infoset models an XML document in terms of a set of 'information items'. The set ofpossible information items generally maps to the various features in an XML document, suchas elements, attributes, namespaces, and comments. Each information item has anassociated set of properties that provide a more complete description of the item. Theeleven types of information items in an XML document are described in Appendix B. Everywell-formed XML document consists of exactly one document information item and at leastone element information item.

In addition to the pure text-based encoding of the Infoset, the Web services architecture alsosupports an Infoset encoding that allows opaque binary data to be interleaved withtraditional text-based markup. The W3C XML-binary Optimized Packaging (or XOP [XOP])format uses multi-part MIME [MIME] to allow raw binary data to be included into an XML 1.0document without resorting to base64 encoding. A companion specification, SOAP Message

Transmission Optimization Method, or MTOM, [MTOM], then specifies how to bind this formatto SOAP. XOP and MTOM are the preferred approach for mixing raw binary with text-basedXML and replaces the now deprecated SOAP with Attachments (SwA) and WS-Attachments/DIME.
http://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#wsawhitepapermsdn040825_ref_ws_addressinghttp://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#wsawhitepapermsdn040825_ref_xml_infosethttp://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#wsawhitepapermsdn040825_ref_xml_10http://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#wsawhitepapermsdn040825_ref_xmlschemahttp://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#wsawhitepapermsdn040825_ref_xml_queryhttp://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#wsawhitepapermsdn040825_ref_xslt_20http://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#wsawhitepapermsdn040825_ref_xophttp://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#wsawhitepapermsdn040825_ref_mimehttp://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#wsawhitepapermsdn040825_ref_mtomhttp://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#wsawhitepapermsdn040825_ref_ws_addressinghttp://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#wsawhitepapermsdn040825_ref_xml_infosethttp://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#wsawhitepapermsdn040825_ref_xml_10http://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#wsawhitepapermsdn040825_ref_xmlschemahttp://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#wsawhitepapermsdn040825_ref_xml_queryhttp://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#wsawhitepapermsdn040825_ref_xslt_20http://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#wsawhitepapermsdn040825_ref_xophttp://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#wsawhitepapermsdn040825_ref_mimehttp://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#wsawhitepapermsdn040825_ref_mtom


8/41

SOAP

SOAP provides a simple and lightweight mechanism for exchanging structured and typedinformation between peers in a decentralized, distributed environment using XML. SOAP wasdesigned to reduce the engineering cost of integrating applications built on differentplatforms as much as possible with the assumption that the lowest-cost technology has the

best chance of gaining universal acceptance. A SOAP message is an XML documentinformation item that contains three elements: , , and .

The Envelope is the root element of the SOAP message and contains an optional Headerelement and a mandatory Body element. The Header element is a generic mechanism foradding features to a SOAP message in a decentralized manner. Each child element ofHeader is called a header block, and SOAP defines several well-known attributes that can beused to indicate who should deal with a header block (role) and whether processing it isoptional or mandatory (mustUnderstand), both described below. When present, the Headerelement is always the first child element of the Envelope. The Body element is always thelast child element of the Envelope, and is a container for the "payload" intended for theultimate recipient of the message. SOAP itself defines no built-in header blocks and only onepayload, which is the Fault element used for reporting errors.

All Web services messages are SOAP messages that take full advantage of the XML Infoset.The fact that both the message payload and the protocol headers employ the same modelcan be used to ensure the integrity of infrastructure headers as well as application bodies.Applications may route messages based on the content of both the headers and the datainside the message. Tools that have been developed for the XML data model may be usedfor inspecting and constructing complete messages. These benefits were not available inarchitectures such as DCOM, CORBA, and RMI, where protocol headers were infrastructuraldetails opaque to the application.

SOAP messages are transmitted one-way from sender to receiver. Multiple one-waymessages can be combined into more sophisticated patterns. For instance, a popularpattern is a synchronous request/response pair of messages.

Any software agent that sends or receives messages is called a SOAP node. The node thatperforms the initial transmission of a message is called the original sender. The final nodethat consumes and processes the message is called the ultimate receiver. Any node thatprocesses the message between the original sender and ultimate receiver is called anintermediary. Intermediaries are used to model the distributed processing of an individualmessage. The collection of intermediary nodes traversed by the message and the ultimatereceiver are collectively referred to as the message path.

To allow parts of the message path to be identified, each node participates in one or moreroles. SOAP roles are a categorization scheme that associates a URI-based [RFC1630] namewith abstract functionality (e.g., caching, validation, authorization). The base SOAP

specification defines two built-in roles: Next and UltimateReceiver. Next is a universal role inthat every SOAP node other than the sender belongs to the Next role. UltimateReceiver isthe role that the terminal node in a message path plays. This is typically the application, orin some cases, infrastructure that is performing work on behalf of the application.

The body of a SOAP envelope is always targeted at the ultimate receiver. In contrast, SOAPheaders may be targeted at intermediaries or the ultimate receiver. To provide a safe andversionable model for processing messages, SOAP defines three attributes that control howintermediaries and the ultimate receiver process a given header blockrole, relay, andmustUnderstand. The role attribute is used to identify which node the header block is
http://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#wsawhitepapermsdn040825_def_soap_intermediaryhttp://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#wsawhitepapermsdn040825_def_message_pathhttp://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#wsawhitepapermsdn040825_ref_rfc1630http://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#wsawhitepapermsdn040825_def_soap_intermediaryhttp://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#wsawhitepapermsdn040825_def_message_pathhttp://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#wsawhitepapermsdn040825_ref_rfc1630


9/41

targeted at. The mustUnderstand attribute indicates whether that node may ignore theheader block if it is not recognized. Header blocks marked mustUnderstand="true" arecalled mandatory header blocks. Header blocks marked mustUnderstand="false" or thathave no mustUnderstand attribute are called optional header blocks. The relay attributeindicates whether that node should forward unrecognized optional headers or discard them.

Every SOAP node must use these three attributes to implement the SOAP processing model.The following steps define that model:

1. Identify all header blocks of the SOAP message intended for the current SOAP nodeusing the role attribute (the absence of this attribute implies the header block is forthe ultimate receiver).

2. Verify that all mandatory header blocks identified in Step 1 can be processed by thecurrent SOAP node using the SOAP mustUnderstand attribute. If a mandatory headerblock cannot be processed by the current SOAP node, the message must bediscarded and a distinguished fault message must be generated.

3. Process the message. Optional message elements may be ignored.4. If the SOAP node is not the ultimate receiver of the message, all header blocks

identified in Step 1 that are not relayable are removed and the message is then

relayed to the next SOAP node in the message path. The SOAP node is free to insertnew header blocks into the relayed message. Some of these header blocks may becopies of header blocks identified in Step 1.

The SOAP processing model is designed to allow extensibility and versioning. ThemustUnderstand attribute controls whether the introduction of a new header block is abreaking or non-breaking change. Adding optional headers blocks (e.g., headers markedmustUnderstand="false") is a non-breaking change, as any SOAP node is free to ignore it.Adding mandatory headers blocks (e.g., headers marked mustUnderstand="true") is abreaking change, in that only SOAP nodes that are aware of the header block's syntax andsemantics are able to process the message. The role and relay attributes compose withmustUnderstand to distribute this processing model along a message path.

Message Exchange Patterns

The messaging flexibility provided by SOAP allows services to communicate using a varietyof message exchange patterns, satisfying the requirements of distributed applications. Weexploit several of them in the core building blocks of the architecture. Several patterns haveproven particularly useful in distributed systems. The use of remote procedure calls, forexample, popularized the synchronous request/response message exchange pattern. Whenmessage delivery latencies are uncontrolled, asynchronous messaging is needed. When theasynchronous request/response pattern is used, explicit message correlation becomesmandatory.

Broadcast transports popularized one-to-many message transmissions. The original sender

imposing its messages on the recipients by just sending them is referred to as the pushmodel. While this model is effective in local-area networks, it does not scale well to wide-area networks nor offer recipients an option to regulate the message flow.

Another useful pattern is based on an application's ability to express interest in particularkinds of messages, making the publish/subscribe pattern quite popular. By explicitlysubscribing to message sources (or topics), applications have a more controlled flow ofrelevant information.


10/41

The pull model is used when a recipient explicitly requests a message from a source. Thismakes message flow the recipient's responsibility. The pull pattern can also be combinedwith publish/subscribe. It is well suited for situations where recipients may be intermittentlydisconnected from the sources.

Transport Independence

SOAP is defined independently of the underlying messaging transport mechanism in use. Itallows the use of many alternative transports for message exchange, and allows bothsynchronous and asynchronous message transfer and processing.

One example of a system that requires both multiple transports and asynchronousmessaging is one that communicates between a Web service on a land-based, high-speednetwork backbone and an intermittently connected Web service hosted on a cellular phone.Such a system requires a single message to travel over different transports depending onwhich network hop the message is moving between. Such a system also shows one exampleof where message delivery latency cannot be accurately determined. Instead of attemptingto determine or bound message delivery latency, the Web service developer should buildthe system assuming the full power of asynchronous message passing. Unlike when using

remote procedure calls, asynchronous messaging allows the sender to continue processingafter each message transmission without being forced to block and wait for a response. Ofcourse, synchronous request-response patterns can be built on the foundation ofasynchronous messaging.

Since Web service protocols are designed to be completely independent of the underlyingtransport, selection of the appropriate mechanism can be deferred until runtime. This allowsWeb service applications the flexibility to determine the appropriate transport as themessage is sent. Additionally, the underlying transport may change as the message isrouted between nodes, and again, the mechanism selected for each hop can vary asrequired.

Despite this general transport independence, most first-generation Web servicescommunicate using HTTP, as this is one of the primary bindings included within the SOAPspecification. HTTP uses TCP as its underlying transport protocol. However, TCP's designintroduces processing overhead this is not always necessary. Several application protocolpatterns more closely match the semantics of the User Datagram Protocol, or UDP [UDP].

These patterns are particularly useful for devices and other resource-constrained systems.

UDP does not have the delivery guarantees of TCP; it provides best-effort datagrammessaging. It also requires fewer resources to implement than TCP. In addition, UDPprovides multi-cast capabilities, allowing a sender to simultaneously transmit a message tomultiple recipients. The specifications for binding SOAP messages to UDP are published inSOAP-over-UDP [SOAP-UDP].

Addressing

For messages to be routed and addressed in this multi-transport world, a commonmechanism is needed for critical messaging properties to be carried across multipletransports. The WS-Addressing specification defines three sets of SOAP header blocks forthis purpose.
http://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#wsawhitepapermsdn040825_ref_udphttp://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#wsawhitepapermsdn040825_ref_soap_udphttp://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#wsawhitepapermsdn040825_ref_udphttp://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#wsawhitepapermsdn040825_ref_soap_udp


11/41

The Action header block is used to indicate the expected processing of a message. Thisheader block contains a single URI that is typically used by the ultimate recipient to dispatchthe message for processing.

The MessageID and RelatesTo header blocks are used to identify and correlate messages.The MessageID and RelatesTo headers use simple URIs to uniquely identify messages

typically these URIs are transient UUIDs.

The To/ReplyTo/FaultTo header blocks are used to identify the agents that are to process themessage and its replies. These headers rely on a WS-Addressing-defined structure called anendpoint reference that bundles together the information needed to properly address aSOAP message.

Endpoint references are the most important aspect of WS-Addressing, as they providesupport for finer-grained addressing than just a URI. They are used extensively throughoutthe Web services architecture. Endpoint references contain three critical pieces ofinformation: a base address, and optional sets of reference properties and referenceparameters. The base address is a URI that is used to identify an endpoint, and appears inthe To header block of every SOAP message targeted at that endpoint. Reference properties

and reference parameters are collections of arbitrary XML elements used to complement thebase address by providing additional routing or processing information for the message.

They are represented as literal header elements. When using an endpoint reference toconstruct a message for the endpoint, the sender is responsible for including all referenceproperties and reference parameters as header blocks.

The distinction between reference properties and reference parameters is in how they relateto a service's metadata. The policy and contract of a Web service is based on its baseaddress and reference properties only. Typically, the base address and reference propertiesidentify a given deployed service and the reference parameters are used to identify specificresources that are managed by that service.

Reference properties and parameters are simply opaque XML elements that are expected tobe processed by only the ultimate receiver. They help ensure that information that can beused for dispatch, routing, indexing, or other sender-side processing activities is includedwith a given message. While intermediaries are not expected to process this information, itis possible that some intermediaries, such as firewalls or gateway services, may use certainreference properties or parameters for message routing and/or processing.

There are many uses for reference properties. Two simple examples are classes of serviceand private entity identifiers. In the class of service example, reference properties may beused to differentiate between a Web service for standard customers and one for "gold"customers that provides a higher quality of service and enhanced capabilitiespossiblythrough extra operations or additional bindingslogically forming two different endpoints.Properties such as these are set only once in a session and then reused throughout the restof the interaction. An example of a second kind of use of a reference property is amechanism to identify a customer in a manner private to the originating system. Acombination of these two types of reference properties could enable efficient messagedispatch to the appropriate collection of servers and efficiently finding the application statethat relates to a particular user. These examples also show how data that refers to instancesof services and data that refers to instances of users can be represented in referenceproperties.

In particular, reference properties also help address collections of WSDL entities that share acommon URL and scope. WSDL, the XML format for describing Web services as a set of
http://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#wsawhitepapermsdn040825_def_resourcehttp://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#wsawhitepapermsdn040825_def_resource


12/41

endpoints operating on messages, first specifies its entities abstractly, and then concretelybinds them to specific instances. In particular, messages and operations are abstractlydefined, and are then bound to an endpoint with network transport and message formatinformation. So, from the WSDL perspective, when targeting different concrete entities, likeinput or output messages, portType bindings, ports, or services in a Web service using acommon URL, the corresponding Endpoint Reference's reference properties should be

different. WSDL is presented in more detail in the Metadata section.

Two examples of reference parameter use are infrastructural and application-level. Aninfrastructural example of a reference parameter can be a transaction/enlistment ID sent toa Transaction Processing monitor. In a book-purchase scenario, the ISBN number of a bookcan be an application-level example of a reference parameter.

Metadata

All Web service interaction is performed by exchanging SOAP messages as described in theprevious section. To provide for a robust development and operational environment,services are described using machine-readable metadata. Metadata enables interoperability.

Web service metadata serves several purposes. It is used to describe the messageinterchange formats the service can support, and the valid message exchange patterns of aservice. Metadata is also used to describe the capabilities and requirements of a service.

This last form of metadata is called the policy of a service. Message interchange formats andmessage exchange patterns are expressed in WSDL. Policies are expressed using WS-Policy.Contracts are expressed using all three kinds of metadata described above. Contracts areabstractions that insulate applications from the internal implementation details of theservices they rely upon.

The Web Service Description Language, or WSDL, was the first widely adopted mechanismfor describing the basic characteristics of a Web service. Messages described in WSDL aregrouped into operations that define the basic message patterns. The operations are groupedinto interfaces called ports that specify an abstract contract for a service. Finally, ports and

bindings are used to associate portTypes with concrete transports and physical deploymentinformation. A WSDL description is a first step in automatically identifying all characteristicsof the target service and enabling software development tools.

WSDL specifies what a request message must contain and what the response message willlook like in unambiguous notation. The notation that a WSDL file uses to describe messageformats is based on XML Schema. This means it is both programming-language neutral andstandards-based, which makes it suitable for describing service interfaces that areaccessible from a wide variety of platforms and programming languages. In addition todescribing message contents, WSDL may define where the service is available and whatcommunications protocol is used to talk to the service. This means that the WSDL file canspecify the base elements required to write a program to interact with a Web service.Several tools are available to read a WSDL file and generate the code required to produce

syntactically correct messages for a Web service.

While WSDL is a good starting point, it is not sufficient to describe all aspects of a Webservice. WSDL allows only a rather small set of properties to be expressed. Examples ofmore detailed information that is necessary for Web services include the following:

Operational characteristics: The service supports SOAP version 1.2.

Deployment characteristics: The service is available only between 9 a.m. and 5 p.m.


13/41

Security characteristics: Kerberos [KERBEROS] tickets are required for access to theservice.

First generation Web services must exchange metadata out of band using proprietaryprotocols. This issue is addressed with WS-Policy [WS-Policy]. WS-Policy provides a general-purpose model and syntax to describe and communicate the policies of a Web service. It

specifies a base set of constructs that can be used and extended by other Web servicespecifications to describe a broad range of service requirements and capabilities. WS-Policyintroduces a simple and extensible grammar for expressingpolicy assertions and a processingmodel to interpret them. Assertions may be combined into logical alternatives.

Policy assertions allow programmers to add appropriate metadata to service informationeither at development time or at runtime. Examples of development time policies includethe maximum allowed message size, or the exact version of a supported specification.Examples of runtime policies include mandatory service down time or the unavailability of aWeb service during a given administrative procedure such as regular hardwaremaintenance. Examples of policies that relate to security are presented later in this paper.

Individual policy assertions may be grouped to formpolicy alternatives . Policies are collections of

policy alternatives. To facilitate interoperability, policies are defined in terms of their XMLInfoset representation. A compact form for policies is defined to reduce the size of policydocuments while preserving interoperability.

Policies are used to convey conditions for interaction between two Web service endpoints.Satisfying assertions in a policy usually results in behavior that reflects these conditions.

Thus, policy assertion evaluation is central to identifying compatible behaviors. A policyassertion, the building block for policies, is supported by a requestor if and only if therequestor satisfies the requirement, or accommodates the capability, corresponding to theassertion. In general, this determination uses domain-specific knowledge. A policyalternative is supported by a requestor if and only if the requestor supports all the assertionsin the alternative. This is determined mechanically using the results of the policy assertions.Also, a policy is supported by a requestor if and only if the requestor supports at least one of

the alternatives in the policy. This determination is also mechanical once the policyalternatives have been evaluated. Note that although policy alternatives are meant to bemutually exclusive, it cannot be decided in general whether or not more than onealternative can be supported at the same time.

To convey policy in an interoperable form, apolicy expression is an XML Infoset representationof a policy. The normal form policy expression is the most straightforward Infoset;equivalent, alternative Infosets allow compactly expressing a policy through a number ofconstructs. Policy expressions are the base building block for policies. Two operators areused to express their assertions: All and ExactlyOne. The All operator specifies that all theassertions present in a collection of policy alternatives have to hold for the policy assertionto be satisfied. The ExactlyOne operator specifies that exactly one of the assertions presentin a collection of policy alternatives has to hold for the policy assertion to be satisfied.

Policies layer on top of, and augment, WSDL descriptions. Policies are associated with Webservices metadata, such as WSDL definitions or UDDI [UDDI] entities through the use of WS-PolicyAttachment [WS-PA]. Policies may be associated with resources either as an intrinsicpart of their definition, or separately. Mechanisms are defined for each of these purposes. Inparticular, policies may also be used with individual SOAP messages. When multiple policyattachments are made for an entity, they jointly determine the effective policy for the entity.Care must be taken when attaching policies at different levels of the WSDL hierarchy, sincethe net result for each level of a hierarchy is the effective policy. As a general rule for self-
http://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#wsawhitepapermsdn040825_ref_kerberoshttp://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#wsawhitepapermsdn040825_ref_ws_policyasserthttp://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#wsawhitepapermsdn040825_def_policy_assertionhttp://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#wsawhitepapermsdn040825_def_policy_assertionhttp://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#wsawhitepapermsdn040825_def_policy_alternativehttp://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#wsawhitepapermsdn040825_def_policyhttp://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#intr_def_policy_expressionhttp://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#wsawhitepapermsdn040825_ref_uddihttp://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#wsawhitepapermsdn040825_ref_ws_pahttp://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#intr_def_effective_policyhttp://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#wsawhitepapermsdn040825_ref_kerberoshttp://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#wsawhitepapermsdn040825_ref_ws_policyasserthttp://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#wsawhitepapermsdn040825_def_policy_assertionhttp://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#wsawhitepapermsdn040825_def_policy_alternativehttp://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#wsawhitepapermsdn040825_def_policyhttp://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#intr_def_policy_expressionhttp://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#wsawhitepapermsdn040825_ref_uddihttp://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#wsawhitepapermsdn040825_ref_ws_pahttp://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#intr_def_effective_policy


14/41

description and human-understandable clarity, it is preferable to be verbose and repeat apolicy assertion at each level of a hierarchy that it applies, than to be terse and rely on themechanism that computes the effective policy. In a WSDL document a message exchangewith a deployed endpoint could contain effective policies in all four subject typessimultaneously.

The combination of WS-Policy and WS-PolicyAttachment provides an increased ability toprogrammatically discover and reason about the policies supported by other services.Flexibility to add policies is an important complement to the WSDL information thatdescribes the message interactions.

WSDL and WS-Policy both define formats for metadata but do not specify mechanisms foracquiring or accessing metadata for a given service. In general, service metadata can bediscovered using a variety of techniques. To enable services to be self-describing, Webservices architecture defines SOAP-based access protocols for metadata in WS-MetadataExchange [WS-MEX]. The GetMetadata operation is used to retrieve metadatathat is found at the endpoint reference of the request. The Get operation is similar but isdesigned to retrieve metadata that is referenced in a metadata section, and is to beretrieved at the endpoint reference where it is stored.

The metadata exchanged using WS-MEX can be described as a resource. A resource isdefined as any entity addressable by an endpoint reference where the entity can provide anXML representation of itself. Resources form the basis needed to build state management inWeb services.

What Are Interoperability Profiles?

A Profile is a set of guidelines for the use of Web services specifications beyond the coreprotocols. These guidelines are necessary because of the specification's general-purposedesign. In some instances, developers need additional help in determining which Webservices features should be used to meet a particular requirement. Interoperability Profilesalso resolve ambiguities in areas where the Web services specifications are not clear enough

to ensure that all implementations process SOAP messages in the same way.The WS-I Basic Profile

The first Web services profiles were published by the Web Services-InteroperabilityOrganization (WS-I) [WS-I]. WS-I has finalized its first profile, simply titled the Basic Profile1.0 [WSI-BP10]. This profile provides guidance primarily on the interoperable use of SOAP 1.1and WSDL 1.0.

Security

This section presents the specifications used in the Web services architecture to providemessage integrity, authentication and confidentiality, security token exchange, messagesession security, security policy expression, and security for a federation of services within asystem. The specifications providing these features are WS-Security, WS-Trust [WS_Trust],WS-SecureConversation [WS-SecureConv], WS-SecurityPolicy [WS-SecurityPolicy], and WS-Federation [WS_Federation].

Security is a fundamental aspect of computer systems, especially those systems comprisedof Web services. Security has to be robust and effective. Since systems may only makehard-wired assumptions about the format of messages and legal message exchanges,security must be built based on explicit, agreed-upon mechanisms and assumptions. The
http://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#wsawhitepapermsdn040825_ref_ws_mexhttp://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#wsawhitepapermsdn040825_ref_wsihttp://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#wsawhitepapermsdn040825_ref_wsi_bp10http://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#wsawhitepapermsdn040825_def_authenticationhttp://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#wsawhitepapermsdn040825_def_federationhttp://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#wsawhitepapermsdn040825_ref_ws_trusthttp://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#wsawhitepapermsdn040825_ref_ws_secureconvhttp://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#wsawhitepapermsdn040825_ref_ws_securitypolicyhttp://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#wsawhitepapermsdn040825_ref_ws_federationhttp://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#wsawhitepapermsdn040825_ref_ws_mexhttp://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#wsawhitepapermsdn040825_ref_wsihttp://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#wsawhitepapermsdn040825_ref_wsi_bp10http://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#wsawhitepapermsdn040825_def_authenticationhttp://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#wsawhitepapermsdn040825_def_federationhttp://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#wsawhitepapermsdn040825_ref_ws_trusthttp://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#wsawhitepapermsdn040825_ref_ws_secureconvhttp://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#wsawhitepapermsdn040825_ref_ws_securitypolicyhttp://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#wsawhitepapermsdn040825_ref_ws_federation


15/41

security infrastructure should also be flexible enough to support the wide variety of securitypolicies required by different organizations.

When a secure transport is available between the communicating Web services, such as theSecure Sockets Layer (SSL) and Transport Layer Security (TLS), building a secure solution issimplified. With a secure transport, the services need not concern themselves with

maintaining integrity and confidentiality for individual messages; they can rely on theunderlying transport. However, existing transport-level security is a solution limited only topoint-to-point messaging. If intermediaries are present when using a secure transport, theinitial sender and the ultimate receiver need to trust those intermediaries to help provideend-to-end security, since each hop is secured separately. In addition to explicit trust of allintermediaries, other risks such as local storage of messages and the potential for anintermediary to be compromised must be considered.

To maximize the reach of Web services, end-to-end security must be provided whenintermediaries are not trusted by the communicating endpoints. This requires higher-levelsecurity protocols. End-to-end message security is a richer alternative to point-to-pointtransport-level security, since it supports the loosely coupled, federated, multi transport, andextensible environment that SOAP-based Web services require. This powerful and flexible

infrastructure can be developed from a combination of existing technologies and Webservices protocols while mitigating many of the security risks associated with point-to-pointmessaging.

Even though the security requirements for Web services are complex, no new securitymechanisms were invented to satisfy the needs of SOAP-based messaging. Existingapproaches to distributed systems security, such as Kerberos tickets, public key encryptiontechnologies, X.509 [X509] certificates, and others proved to be sufficient. New mechanismswere necessary only to apply these existing security approaches to SOAP. These newsecurity protocols were designed with extensibility in mind in order to allow new approachesto be incorporated in the future. A primary design objective was to provide mechanisms forself-describing security properties designed for SOAP and the rest of the Web servicesarchitecture.

Web services security is based on the requirement that incoming messages prove a set ofassertions made about a sender, a service or other resource. We call these claims, or securityassertions. Examples of security claims include identity, attributes, key possession,permissions, or capabilities. These assertions are encoded in binary security tokens wrappedin XML. In traditional security terminology, these security tokens represent a mix ofcapabilities and access controls.

Various approaches are used to create security tokens. A Web service may build a customsecurity token from local information. Alternately, a security token may be retrieved fromspecialized services such as a X.509 certificate authority or a Kerberos domain controller. Toautomate communication between services, a mechanism to express security requirementsis required.

Services may express their security requirements using policy assertions as specified in WS-SecurityPolicy. This specification is described in a later subsection of this paper. Byretrieving these policy assertions, an application may build messages that comply with therequirements of the target service. This combination of features provided by claims, securitytokens and policies, and the ability to retrieve them from a Web service is powerful.

The general Web services security model supports several more specific security models,such as identity-based authorization, access control lists, and capabilities-based
http://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#wsawhitepapermsdn040825_ref_x509http://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#wsawhitepapermsdn040825_def_claimhttp://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#wsawhitepapermsdn040825_ref_x509http://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#wsawhitepapermsdn040825_def_claim


16/41

authorization. It allows the use of existing technologies such as X.509 public-key certificates,XML-based tokens, Kerberos shared-secret tickets, and password digests. The general modelis sufficient to construct systems that use more sophisticated approaches for higher-levelkey exchange, authentication, policy-based access control, auditing, and complex trustrelationships. Proxies and relay services may also be used. For example, a relay service canbe built to enforce a security policy at a trust boundary; messages going outside the

boundary are encrypted while those that stay within the boundary are unencrypted. Thisflexibility and degree of sophistication is not present in previous solutions.

The common security attacks described in Appendix C include a base taxonomy of systemthreats that should be carefully considered when choosing Web services security features.

The remainder of this section explores the application of the Web services security model.The two key topics are securing communications and securing applications. A securemessage transport is not assumed, nor is it necessary for secure Web services.

Message Integrity and Confidentiality

Message-level security is the key building block for end-to-end security. When usingmessage-level security, no transport-level security is required. Requirements for message-level security are message integrity, message authentication, and confidentiality. Messageintegrity ensures that a message cannot be changed without detection. Use of XMLSignature [XMLSIG] ensures that message modifications can be detected.

Message authentication identifies the principal that sent the message. If public keyencryption is used, the unique identity of the principal can be determined. The use of publickey encryption with keys certified by a trusted source provides this authentication. However,ifsymmetric key encryption is used, this is not the case only the group of principals that knowthe shared secret can be identified.

Message confidentiality ensures that a message cannot be read by an unauthorized third

party during transmission. SOAP messages are kept confidential through the use of XMLEncryption [

XMLENC] in conjunction with security tokens.

Mechanisms for integrity, authentication, and confidentiality take the original message (orparts of the message) as input, and product-appropriate data (such as a checksum) asoutput. For example, the signatureof an XML element could, in a simple case, be implementedas the asymmetric encryption of a hash of all the characters of the XML element. Thisencrypted hash could then be stored and transmitted in the message.

XML documents can be thought of as strings of characters. The character-by-character

comparison is critical security operations such as XML signatures. A one-character differenceis a different result. Serialization is the method used to represent objects "on the wire". Forexample, serialization is used to create the XML representation of a SOAP message. Anyinessential typographical variations produced by different serialization software are ignoredby message processing software, but significantly impact the security software. The Infosetrepresentation of an XML message ameliorates this issue. For XML signatures to workmessages must be transformed to an XML form that is consistent for all parties.Canonicalization is the term used to describe the method used to produce a consistent view ofthe non-critical information such as line breaks, tab spaces, ordering of attributes and the
http://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#wsawhitepapermsdn040825_def_digesthttp://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#wsawhitepapermsdn040825_def_digesthttp://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#wsawhitepapermsdn040825_ref_xmlsighttp://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#wsawhitepapermsdn040825_def_symmetric_keyhttp://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#wsawhitepapermsdn040825_def_signaturehttp://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#wsawhitepapermsdn040825_def_signaturehttp://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#wsawhitepapermsdn040825_def_serializationhttp://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#wsawhitepapermsdn040825_def_canonicalizationhttp://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#wsawhitepapermsdn040825_def_digesthttp://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#wsawhitepapermsdn040825_ref_xmlsighttp://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#wsawhitepapermsdn040825_def_symmetric_keyhttp://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#wsawhitepapermsdn040825_def_signaturehttp://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#wsawhitepapermsdn040825_def_serializationhttp://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#wsawhitepapermsdn040825_def_canonicalization


17/41

style of closing tags. Signatures include the canonicalization method used to enable therecipient of a message to process the security information in a manner consistent with thesender. The specific canonicalization method in use by a service is a useful policy assertionto place at a WSDL portType binding or a WSDL Port.

WS-Security specifies mechanisms for message integrity and confidentiality, and single

message authentication. For message integrity, the specification details how a cryptographicsignature is represented and associated with specific parts of the SOAP message. Theapproach allows arbitrary well-formed fragments of the message to have separatesignatures. In a similar manner, confidentiality is achieved through the encryption of well-formed fragments of the message. Authentication is achieved using digital signatures.

The WS-Security specification describes common security mechanisms in use today, butdoes not preclude new ones from being added in the future. Since the SOAP processingmodel uses the header elements to make processing decisions, great care must beexercised when deciding which elements in a SOAP message to encrypt.

Web service designers must be aware of how the message will be processed in decidingwhich elements are to be encrypted and which encryption algorithms to use. These

decisions are even more important when specific header elements need to be processed bythird parties or intermediaries. If those parties are not privy to the appropriate decryptiondata, or to the conventions used in encrypting the XML elements, they will not be able tooperate correctly. In addition, each processing node must have a common understanding ofthe security information included in the message.

One natural choice for encrypting an XML element in a header is to encrypt it completely,substituting the original element for one that is of type encrypted data. Drawbacks to thisstraightforward approach exist. Intermediaries, for example, have a hard time determiningwhich elements must be processed (those adorned with the mustUnderstand="1"attribute). Also, as the element type is changed, determining its original type is difficult.

An alternative approach is to transform the element to one where all the key attributesneeded for correct SOAP processing are preserved and the original element is encrypted andplaced in a distinguished sub-element. The advantage of this approach is that correctprocessing can be achieved even by intermediaries that do not know how to decrypt theelement. A drawback to this approach is that it requires the convention used to representthe original element to be understood by all parties. While WS-Security does not currentlyprovide guidance on this approach, we expect future work to do so. The alternate method ispreferred because it enables the correct processing of all SOAP header elements.

Several kinds of security tokens are described in WS-Security's profile specifications. Profileshave been developed for tokens representing user names, X.509 certificates, and XML-based security tokens. XML-based security tokens include the Security Assertion MarkupLanguage (SAML) [SAML] and the eXtensible rights Markup Language/Rights ExpressionLanguage (REL) [REL]. Specifications for the use of Kerberos tickets are also underdevelopment.

The WS-I Basic Security Profile

One of the newest interoperability Profiles to be published by WS-I is the Basic SecurityProfile (BSP) [WSI-BSP10]. This Profile provides implementation guidance for WS-Security andvarious security tokens, such as Username [WS-SecUsername] and X.509 certificate tokens[WS-SecX509]. It is designed to complement and compose with the WS-I Basic Profile.
http://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#wsawhitepapermsdn040825_ref_samlhttp://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#wsawhitepapermsdn040825_ref_relhttp://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#wsawhitepapermsdn040825_ref_wsi_bsp10http://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#wsawhitepapermsdn040825_ref_ws_secusernamehttp://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#wsawhitepapermsdn040825_ref_wssec_x509http://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#wsawhitepapermsdn040825_ref_samlhttp://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#wsawhitepapermsdn040825_ref_relhttp://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#wsawhitepapermsdn040825_ref_wsi_bsp10http://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#wsawhitepapermsdn040825_ref_ws_secusernamehttp://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#wsawhitepapermsdn040825_ref_wssec_x509


18/41

Trust Based on Security Tokens

Security tokens are required to provide an end-to-end security solution. These securitytokens must be shared, either directly or indirectly, between the parties involved in messageprocessing. Each party also must determine if the asserted credentials can be trusted. Thesetrust relationships are based on the exchange and brokering of security tokens and in the

supporting trust policies that have been established. How much of a brokered token istrusted, for example, is determined by system administrators and the trust relationshipsthey have established.

Services that provide security tokens can be quite varied. This is where each of theunderlying security technologies is first used by a Web service. In order to provide a uniformsolution irrespective of the security technology, new protocols were designed for securitytoken exchange between trust domains.

WS-Trust [WS-Trust] complements WS-Security with protocols for requesting, issuing andbrokering security tokens. In particular, operations to acquire, issue, renew, and validatesecurity tokens are defined. Another feature of the specification is a mechanism to brokernew trust relationships. Network and transport protection mechanisms such as IPsec or

TLS/SSL can be used in conjunction with WS-Trust for different security requirements andscenarios.

Security token acquisition can be done directly by explicitly requesting one from anappropriate issuer, or indirectly by delegating the acquisition to a trusted third party. Tokensmay also be acquired out-of-band. For example, the token may be sent from a securityauthority to a party without the token having been explicitly requested. To complete thepicture, system administrators determine initial trust relationships designating, for example,a given service as a trusted root service. This approach is similar to what is used tobootstrap security on the Web today. All tokens obtained from this service are trusted to thesame extent as the trusted root itself. For example, if a root is trusted for only claims A andB, and a message contains claims A, B and C, then only claims A and B in the message aretrusted. Configuration flexibility is provided through trust relationship delegation.

To address scenarios where a set of exchanges between the parties is required prior toreturning, or issuing, a security token, mechanisms are specified for validation, negotiationand exchange. A particular form of exchange called a "challenge" provides a mechanism fora party to prove that it possesses a secret associated with a token. Other types ofexchanges include legacy protocol tunneling. WS-Trust defines how to extend thespecification for additional token exchange protocols beyond these two examples.

Security tokens expressing security claims are issued by a trusted root or one through adelegation chain. These security claims are used to verify that the message complies withthe security policies in place. They also verify that the attributes of the claimant are provenby the signatures. In brokered trust models, i.e., those where a trusted intermediary

dispenses security tokens, the signature may not verify the identity of the claimant, but mayinstead verify the identity of the intermediary. This intermediary may simply assert theidentity of the claimant.

Secure Sessions

Some mechanisms for message authentication and confidentiality can be computationallyexpensive. In particular, many encryption techniques consume substantial processingpower. These costs are generally unavoidable when messages are secured individually.


19/41

However, when two Web services exchange many messages, more efficient and robustapproaches for message confidentiality than those defined in WS-Security are available.

These mechanisms, based on symmetric encryption, should be used when securing sessionsof messages.

WS-SecureConversation [WS-SecConv] defines a security context between two communicating

parties based on shared secrets, such as symmetric encryption. A security context is sharedbetween the parties for the lifetime of a session. Session keys are derived from a sharedsecret and are used to decrypt the individual messages sent in the conversation. Thesecurity context is represented on the wire as a new security token type (the Security ContextToken, or SCT).

Three different ways of establishing a security context among the parties of a secureconversation are defined. First, a security token service may create them, and the initiating partyhas to fetch it to propagate it. Second, one of the communicating parties creates thesecurity context and propagates it in a message to the other party. Third, the securitycontext is created through negotiation and exchanges. Web services select the approachmost appropriate for their needs.

Security contexts can be amended when necessary. An example of a requirement to updatea security context is the need to extend the context's expiration time.

A security context token implies or contains a shared secret. This secret is used for signingand/or encrypting messages. When using a shared secret, the parties may choose adifferent key derivation pattern to use. For example, four keys may be derived so that twoparties can sign and encrypt using separate keys. In order to keep the keys fresh and tomaintain a high level of security, subsequent derivations should be used. Securing sessionsusing this approach is preferred. The WS-SecureConversation specification defines amechanism to indicate which derivation is being used within a given message. Eachderivation algorithm is identified with a URI.

Security Policies

WS-SecurityPolicy [WS-SecurityPolicy] complements WS-Security by specifying security policyassertions in a language conformant to WS-Policy. Its six assertions relate to security tokens,message integrity, message confidentiality, message visibility to SOAP intermediaries,constraints on the security header, and the age of a message. For example, a policyassertion may require that all messages be signed using public keys from a given authority,or that authentication be based on Kerberos tickets.

System Federations

Application security requires additional mechanisms beyond what we have presented so far.Identities, for example, are valid within a trust domain but most likely meaningless in other

trust domains. For services in different trust domains to be able to validate identities,appropriate mechanisms are needed. WS-Federation defines mechanisms to enable identity,account, attribute, authentication, and authorization information sharing across trustdomains. By using these mechanisms, multiple security domains may federate by allowingand brokering trust of identities, attributes, and authentication among participating Webservices. The specification extends the WS-Trust model to allow attributes and pseudonymsto be integrated into the token issuance mechanism, resulting in a multi-domain identitymapping mechanism. These mechanisms support single sign on, sign outand pseudonyms, anddescribe the role of specialized services, for attributes and pseudonyms.
http://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#wsawhitepapermsdn040825_def_security_contexthttp://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#wsawhitepapermsdn040825_def_security_context_tokenhttp://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#wsawhitepapermsdn040825_def_security_context_tokenhttp://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#wsawhitepapermsdn040825_def_security_token_servicehttp://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#wsawhitepapermsdn040825_ref_ws_securitypolicyhttp://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#wsawhitepapermsdn040825_def_identity_mappinghttp://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#wsawhitepapermsdn040825_def_identity_mappinghttp://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#wsawhitepapermsdn040825_def_single_sign_onhttp://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#wsawhitepapermsdn040825_def_sign_outhttp://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#wsawhitepapermsdn040825_def_sign_outhttp://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#wsawhitepapermsdn040825_def_security_contexthttp://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#wsawhitepapermsdn040825_def_security_context_tokenhttp://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#wsawhitepapermsdn040825_def_security_context_tokenhttp://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#wsawhitepapermsdn040825_def_security_token_servicehttp://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#wsawhitepapermsdn040825_ref_ws_securitypolicyhttp://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#wsawhitepapermsdn040825_def_identity_mappinghttp://msdn.microsoft.com/en-us/library/ms996441(v=MSDN.10).aspx#wsawhitepapermsdn040825_def_identity_mappinghttp://msdn.microsoft.com/en-us/library/ms996441(v

an introduction to the web services architecture and its specifications

Documents