NIST SP 800-95 日本語訳

Special Publication 800-95

Anoop Singhal Theodore Winograd Karen Scarfone

Guide to Secure Web Services

NIST Special Publication 800-95

Recommendations of the National Institute of Standards and Technology

Anoop Singhal Theodore Winograd Karen Scarfone

Computer Security Division Information Technology Laboratory National Institute of Standards and Technology Gaithersburg, MD 20899-8930

August 2007

U.S. Department of Commerce

Carlos M. Gutierrez, Secretary

National Institute of Standards and Technology

William Jeffrey, Director

The Information Technology Laboratory (ITL) at the National Institute of Standards and Technology (NIST) promotes the U.S. economy and public welfare by providing technical leadership for the nation’s measurement and standards infrastructure. ITL develops tests, test methods, reference data, proof of concept implementations, and technical analysis to advance the development and productive use of information technology. ITL’s responsibilities include the development of technical, physical, administrative, and management standards and guidelines for the cost-effective security and privacy of sensitive unclassified information in Federal computer systems. This Special Publication 800-series reports on ITL’s research, guidance, and outreach efforts in computer security and its collaborative activities with industry, government, and academic organizations.

National Institute of Standards and Technology Special Publication 800-95 Natl. Inst. Stand. Technol. Spec. Publ. 800-95, 128 pages (Aug. 2007)

Certain commercial entities, equipment, or materials may be identified in this document in order to describe an experimental procedure or concept adequately. Such identification is not intended to imply recommendation or endorsement by the National Institute of Standards and Technology, nor is it intended to imply that the entities, materials, or equipment are necessarily the best available for the purpose.

Acknowledgements

The authors, Anoop Singhal and Karen Scarfone of the National Institute of Standards and Technology (NIST) and Theodore Winograd of Booz Allen Hamilton, wish to thank their colleagues who contributed technical content to this document, especially Holly Lynne McKinley, Patrick Holley, and Karen Mercedes Goertzel of Booz Allen Hamilton. The authors would like to acknowledge Tim Grance, David Ferraiolo, and Rick Kuhn of NIST, Jeremy Epstein of Web Methods and David Kleiner, Michael Colon, Steven Lavenhar, and Victoria Thompson of Booz Allen Hamilton, for their keen and insightful assistance throughout the development of the document.

The advance of Web services technologies promises to have far-reaching effects on the Internet and enterprise networks. Web services based on the eXtensible Markup Language (XML), SOAP, and related open standards, and deployed in Service Oriented Architectures (SOA) allow data and applications to interact without human intervention through dynamic and ad hoc connections. Web services technology can be implemented in a wide variety of architectures, can co-exist with other technologies and software design approaches, and can be adopted in an evolutionary manner without requiring major transformations to legacy applications and databases.

The security challenges presented by the Web services approach are formidable and unavoidable. Many of the features that make Web services attractive, including greater accessibility of data, dynamic application-to-application connections, and relative autonomy (lack of human intervention) are at odds with traditional security models and controls. The primary purpose of this publication is to inform people about securing Web services. Difficult issues and unsolved problems exist, such as protecting the following:

Functional integrity of the Web services that requires the establishment of trust between services on a transaction-by-transaction basis

Availability in the face of denial of service attacks that exploit vulnerabilities unique to Web service technologies, especially targeting core services, such as discovery service, on which other services rely.

Perimeter-based network security technologies (e.g., firewalls) are inadequate to protect SOAs for the following reasons:

SOAs are dynamic and can seldom be fully constrained to the physical boundaries of a single network.

SOAP is transmitted over HyperText Transfer Protocol (HTTP), which is allowed to flow without restriction through most firewalls.

Moreover, Transport Layer Security (TLS), which is used to authenticate and encrypt Web-based messages, is inadequate for protecting SOAP messages because it is designed to operate between two endpoints. TLS cannot accommodate Web services' inherent ability to forward messages to multiple other Web services simultaneously.

The Web service processing model requires the ability to secure SOAP messages and XML documents as they are forwarded along potentially long and complex chains of consumer, provider, and intermediary services. The nature of Web services processing makes those services subject to unique attacks, as well as variations on familiar attacks targeting Web servers.

Ensuring the security of Web services involves augmenting traditional security mechanisms with security frameworks based on use of authentication, authorization, confidentiality, and integrity mechanisms. This document describes how to implement those security mechanisms in Web services. It also discusses how to make Web services and portal applications robust against the attacks to which they are subject. The following is a summary of security techniques for Web services:

Confidentiality of Web service messages using XML Encryption¹. This is a specification from the World Wide Web Consortium (W3C) and it provides a mechanism to encrypt XML documents.

Integrity of Web service messages using XML Signature². This is a specification produced jointly by the W3C and the Internet Engineering Task Force (IETF). The power of XML Signature is to selectively sign XML data.

Web service authentication and authorization using XML Signature, Security Assertion Markup Language (SAML) and eXtensible Access Control Markup Language (XACML) as proposed by the Organization for Advancement of Structured Information Standards (OASIS) group. SAML and XACML provide mechanisms for authentication and authorization in a Web services environment.

Web Services (WS)-Security³. This specification, produced by OASIS, defines a set of SOAP header extensions for end-to-end SOAP messaging security. It supports message integrity and confidentiality by allowing communicating partners to exchange signed encrypted messages in a Web services environment.

Security for Universal Description, Discovery and Integration (UDDI)⁴. Produced by OASIS, UDDI allows Web services to be easily located and subsequently invoked. Security for UDDI enables publishers, inquirers and subscribers to authenticate themselves and authorize the information published in the directory.

Challenges

While many of the Web services challenges have been met with existing standards, there are a number of challenges that standards organizations are addressing—particularly in the area of Web services discovery and reliability. The Web Services Interoperability Organization (WS-I) acknowledges that there are many challenges that have yet to be addressed. Some examples of these challenges are:

Repudiation of transactions

Secure issuance of credentials

Exploitation of covert channels

Compromised services

Spread of malware, such as viruses and Trojan horses via SOAP messages

Denial of service attacks

Incorrect service implementations.

The following sections discuss several Web services security challenges in detail, including Web services discovery, quality of service and quality of protection, and protection from denial of service attacks.

Discovery

In Web services discovery, participants identify and compose Web Services Description Language (WSDL) specific services based on definitions in a UDDI registry. Due to the potentially large number of service candidates in the registry, performance rankings for algorithms used to search, match and compose services can vary from case to case.

As the set of available Web services expands, advanced tools to help identify services that match a customer’s functional and security requirements become increasingly important. It is important for service providers to describe their service capabilities and service requesters to describe their requirements in an unambiguous and semantic way. Techniques that take advantage of Semantic Web technologies can improve discovery capabilities. The Ontology Web Language for Services (OWL-S) is an example, but more work needs to be done to integrate such technologies into Web service registries. In OWL-S, the service requester can describe the service requirements using terms from a semantic model. Reasoning techniques are then used to find the semantic similarity between the service description and the request to find a set of matching services automatically. While both UDDI and OWL-S can be used to specify the security properties of a Web service, such support is not inherent in the discovery system. However, W3C's Semantic Annotations for WSDL is a step in the direction of merging Web services discovery technology with semantic Web technology. Even with semantic Web services discovery, true automation will require that the requester be able to determine explicitly the security requirements of the provider in addition to its functionality.

End to End Quality of Service and Protection

Most Web services deployed do not provide guarantees for Quality of Service (QoS) or Quality of Protection (QoP) under the scenario of attacks. QoS is important in defining the expected level of performance a particular Web service will have. By prioritizing traffic, overall performance of the system can be improved. The WS-Reliability and WS-ReliableMessaging standards provide some level of QoS. Both standards support guaranteed message delivery and message ordering. The standard considers other QoS parameters, such as rate of failure or average latency, as out of scope because they are usually dealt with by lower layer protocols. For Web services to truly support QoS, existing QoS support must be extended so that the packets corresponding to individual Web service messages can be routed accordingly to achieve predictable performance.

Overlap between OASIS and W3C Standards

Similar and overlapping Web services security standards that are being developed by multiple standard bodies are a source of confusion to system developers. Moreover, these standards are constantly being updated, resulting in interoperability problems. There is a need for more formal specification and testing of standards.

Methodologies for Web Services Security

The main emphasis of Web services security today is on basic infrastructure (e.g., protocols and languages). As technology matures and Web services become widely adopted, there will be a need for methodologies and recommended practices for security to help developers identify assets to be protected, analyze possible attacks, and decide protection levels and tradeoffs.

Availability and Protection from Denial of Service Attacks

Availability enables a Web services application to detect a Denial of Service (DoS) attack, to continue operation as long as possible, and then to gracefully recover and resume operations after a DoS attack. There is a need for techniques to replicate data and services to ensure continuity of operations in the event of a fault. There is also a need for management and monitoring solutions to provide service performance and availability monitoring to meet certain service level objectives.

Security Actions to Consider

The items below are possible actions that organizations should consider; some of the items may not apply to all organizations. In particular, it is necessary to balance these actions against budget requirements and the potential risks an organization’s Web services may face.⁵

Replicate Data and Services to Improve Availability. Since Web services are susceptible to DoS attacks, it is important to replicate data and applications in a robust manner. Replication and redundancy can ensure access to critical data in the event of a fault. It will also enable the system to react in a coordinated way to deal with disruptions.

Use Logging of Transactions to Improve Non-repudiation and Accountability. Non-repudiation and accountability require logging mechanisms involved in the entire Web service transaction. As of early 2007, there are few implemented logging standards that can be used across an entire SOA. In particular, the level of logging provided by various UDDI registries, identity providers, and individual Web services varies greatly. Where the provided information is not sufficient to maintain accountability and non-repudiation, it may be necessary to introduce additional software or services into the SOA to support these security requirements.

Use Threat Modeling and Secure Software Design Techniques to Protect from Attacks. The objective of secure software design techniques is to ensure that the design and implementation of Web services software does not contain defects that can be exploited. Threat modeling and risk analysis techniques should be used to protect the Web services application from attacks. Used effectively, threat modeling can find security strengths and weaknesses, discover vulnerabilities and provide feedback into the security life cycle of the application. Software security testing should include security-oriented code reviews and penetration testing. By using threat modeling and secure software design techniques, Web services can be implemented to withstand a variety of attacks.

Use Performance Analysis and Simulation Techniques for End to End Quality of Service and Quality of Protection. Queuing networks and simulation techniques have long played critical roles in designing, developing and managing complex information systems. Similar techniques can be used for quality assured and highly available Web services. In addition to QoS of a single service, end-to-end QoS is critical for most composite services. For example, enterprise systems with several business partners must complete business processes in a timely manner to meet real time market conditions. The dynamic and compositional nature of Web services makes end-to-end QoS management a major challenge for service-oriented distributed systems.

Digitally Sign UDDI Entries to Verify the Author of Registered Entries. UDDI registries openly provide details about the purpose of a Web service as well as how to access it. Web services use UDDI registries to discover and dynamically bind to Web services at run time. Should an attacker compromise a UDDI entry, it would be possible for requesters to bind to a malicious provider. Therefore, it is important to digitally sign UDDI entries so as to verify the publisher of these entries.

Enhance Existing Security Mechanisms and Infrastructure. Web services rely on many existing Internet protocols and often coexist with other network applications on an organization’s network. As such, many Web service security standards, tools, and techniques require that traditional security mechanisms, such as firewalls, intrusion detection systems (IDS), and secured operating systems, are in effect before implementation or deployment of Web services applications.

Conclusions

Web services are important drivers for the software industry. The primary goal of service-oriented computing is to make a collection of software services accessible via standardized protocols whose functionality can be automatically discovered and integrated into applications. While several standards bodies (such as W3C and OASIS) are laying the foundation for Web services, several research problems must be solved to make secure Web services a reality. Service description, automatic service discovery as well as QoS are some of the important problems that need to be solved.

Web services are increasingly becoming an integral part of organizational information technology (IT) infrastructures—even though there are still unmet security challenges. To this end, the development and deployment of secure Web services is essential to many organizations' IT infrastructures. However, Web service security standards do not provide all of the required properties to develop robust, secure, and reliable Web services. To adequately support the needs of the Web services based applications, effective risk management and appropriate deployment of alternate countermeasures are essential. Defense-in-depth through security engineering, secure software development, and risk management can provide much of the robustness and reliability required by these applications.

The National Institute of Standards and Technology (NIST) developed this document in furtherance of its statutory responsibilities under the Federal Information Security Management Act (FISMA) of 2002, Public Law 107-347.

NIST is responsible for developing standards and guidelines, including minimum requirements, for providing adequate information security for all agency operations and assets; but such standards and guidelines shall not apply to national security systems. This guideline is consistent with the requirements of the Office of Management and Budget (OMB) Circular A-130, Section 8b(3), “Securing Agency Information Systems,” as analyzed in A-130, Appendix IV: Analysis of Key Sections. Supplemental information is provided in A-130, Appendix III.

This guideline has been prepared for use by Federal agencies. It may be used by nongovernmental organizations on a voluntary basis and is not subject to copyright. Attribution is desired and requested.

Nothing in this document should be taken to contradict standards and guidelines made mandatory and binding on Federal agencies by the Secretary of Commerce under statutory authority, nor should these guidelines be interpreted as altering or superseding the existing authorities of the Secretary of Commerce, Director of the OMB, or any other Federal official.

This publication seeks to assist organizations in understanding the challenges in integrating information security practices into SOA design and development based on Web services. This publication also provides practical, real-world guidance on current and emerging standards applicable to Web services, as well as background information on the most common security threats to SOAs based on Web services. This document presents information that is largely independent of particular hardware platforms, operating systems, and applications. Supplementary security mechanisms (i.e., perimeter security appliances) are considered outside the scope of this publication. Interfaces between Web services components and supplementary controls are noted as such throughout this document on a case-by-case basis.

The document, while technical in nature, provides the background information to help readers understand the topics that are discussed. The intended audience for this document includes the following:

System and software architects and engineers trained in designing, implementing, testing, or evaluating Web services

Software developers experienced in XML, C#, Visual Basic for .NET (VB.NET), C, or Java for Web services

Security architects, engineers, analysts, and secure software developers/integrators

Researchers who are furthering and extending service interfaces and conceptual designs.

This document assumes that readers have some minimal Web services expertise. Because of the constantly changing nature of Web services threats and vulnerabilities, readers are expected to take advantage of other resources (including those listed in this document) for more current and detailed information.

The practices recommended in this document are designed to help mitigate the risks associated with Web services. They build on and assume the implementation of practices described in other NIST guidelines listed in Appendix F.

The remainder of this document is organized into five major sections. Section 2 provides background to Web services and portals and their relationship to security. Section 3 discusses the many relevant Web service security functions and related technology. Section 4 discusses Web portals, the human user’s entry point into the SOA based on Web services. Section 5 discusses the challenges associated with secure Web service-enabling of legacy applications. Finally, Section 6 discusses secure implementation tools and technologies.

The document also contains several appendices. Appendix A offers discussion of several attacks commonly leveraged against Web services and SOAs. Appendix B provides an overview of Electronic Business eXtensible Markup Language (ebXML), a Web services protocol suite developed by the United Nations Centre for Trade Facilitation and Electronic Business (UN/CEFACT). Appendices C and D contain a glossary and acronym list, respectively. Appendices E and F list print resources and online tools and resources that may be useful references for gaining a better understanding of Web services and SOAs, security concepts and methodologies, and the general relationship between them.

Organizations are adopting SOA to support their mission critical applications. SOA is a computing paradigm emphasizing dynamic service discovery, composition, and interoperability. Web services are a technology that can be used to implement SOA and are increasingly becoming the SOA implementation of choice.⁶ For a SOA to truly meet its goals, applications must be secure and reliable. A large number of security standards have been proposed for Web services by a number of different organizations. This section provides an overview of Web services, the associated security challenges, and the standards available for securing Web services.

There are various aspects of Web services: messaging, discovery, portals, roles, and coordination. This section uses an example Web service to illustrate the use of each aspect in developing a SOA application. The example consists of a loan processing Web service which relies on two other Web services: an interest rate service and a credit check service.

To define the format of each SOAP message, W3C developed the WSDL. WSDL interfaces are created by each Web service and can be shared to allow dynamic binding. Through dynamic binding, Web services can communicate with newly added services without any additional programming or configuration changes. To facilitate the discovery of Web services, a discovery standard called UDDI was developed. UDDI allows Web services to search for one another dynamically. When combined with WSDL, Web services can easily discover and use new services at run-time without human intervention.

In the bank loan example, the loan service needs to discover the rate service before using it. The rate Web service is listed in the UDDI registry as a Web service capable of providing information about the bank’s rates. When the loan service is initiated, the UDDI registry is accessed and searched for a Web service capable of providing the bank’s rate information. The UDDI registry returned the rate service’s Uniform Resource Identifier (URI) and details about how to access the rate service, which are derived from the WSDL interface. Figure 2-1 illustrates the discovery process.

Rate

1

Service

UDDI Registry

2

Loan

3

Service

Figure 2-1. Web Service Discovery Example

Web service messages are sent across the network in an XML format defined by the W3C SOAP specification. In most Web services, there are two types of SOAP messages: requests and responses.⁷ When a SOAP request is received, the Web service performs an action based on the request and returns a SOAP response. In many implementations, SOAP requests are similar to function calls with SOAP responses returning the results of the function call.

In the bank loan example, the loan service sends SOAP requests to both the credit and rate services to have them perform some calculations on data provided by the user. The loan service must have the credit check results of the individual to receive the loan and information about the current rates provided by the bank. Once both SOAP responses have been received, the loan service can determine whether or not to grant the loan to the user. Figure 2-2 illustrates how the loan Web service functions.⁸

Figure 2-2. Web Service Messaging Example

A Web portal provides a human readable interface to the functionality provided by a Web service. Web portals are essential because many Web services are designed to be initiated on behalf of a user.⁹ Figure 2-3 shows how messages pass between the user and the portal. When the user indicates that a particular action should be performed, the portal sends a SOAP request to the appropriate Web service, receives a SOAP response with the result of the action, and displays an appropriate response to the user. Web portals can provide access to more data sources than Web services alone, but almost all data sources can be implemented as Web services.

Figure 2-3. Example Portal Interface

In the bank loan example, shown in Figure 2-3, a user accesses a Web portal that gives the user the option of taking out a new loan. The user initiates the loan request, causing the Web portal to send a SOAP request to the loan service. Once the loan service completes its calculations, a SOAP response is sent back to the Web portal. The Web portal processes the SOAP response and generates an associated HyperText Markup Language (HTML) page for the user.

The following sections summarize the overarching roles of the constituent components of a Web service-based SOA: requester, provider, and intermediary. These roles are not exclusive: a single Web service may be designed to act as a requester, provider, and intermediary depending on the context of the Web service transaction.

The requester initiates a Web service transaction on its own or on behalf of a user via a portal. The requester service is tasked with ensuring messages are in the proper syntax and taking the security measures required by the provider.

In the loan Web service example, when a user accesses the bank’s Web site and makes a request for a loan, the loan service acts as a requester service and sends requests to the rate service and credit service.

After receiving the user’s credit rating and the current rates, the loan service can then provide the user with a loan or deny the user’s request.

The provider accepts a request from the requester and provides a response based on the input. The provider is responsible for setting the standards for authentication, authorization, encryption, and non-repudiation. The provider communicates its requirements through the extensibility of WSDL, a discovery service, or both. Some requirements may be negotiable, allowing requesters and providers to dynamically determine how to proceed, but at this time WSDL and discovery services do not provide a standard way for negotiating such requirements. Standards are under development to address this shortcoming.

In the loan service example, both the rate service and credit service are providers. When the rate provider receives a request, it performs the necessary calculations to determine the current rates offered by the bank. Once the request has been processed, the provider sends an appropriate response containing the bank’s current rate information. When the credit provider receives a request, it returns a response containing the creditworthiness of the customer.

Web services provide a SOA in which applications are loosely coupled, allowing Web services to dynamically bind to other Web services at run-time depending on the needs of the user or application. Web services publish their functions to the UDDI registry so that other Web services can find needed functionality. This enables the reuse of applications, particularly legacy applications; by developing a Web services interface that is accessible via SOA, organizations can conserve resources used for costly migrations between platforms. Often, this results in a chain of Web service invocations and an associated performance penalty. This penalty, however, is often offset by the savings in development time and consistency of results associated with re-using components.¹⁰ In a network with low latency and high availability, this performance penalty can be minimized to the point that it is not noticeable.

An intermediary service is a Web service that is invoked in a chain. The most common example of an intermediary Web service is an XML gateway that receives requests from requesters, performs security checks against the requests, and then forwards the requests to an internal Web service provider. From the perspective of the requester, there is only a single provider, but in reality there are two. There can be any number of intermediary services involved within a single Web service transaction. Figure 2-4 illustrates how multiple intermediary services may interact with other services.

Figure 2-4. Intermediary Services

In the loan example, both the credit and rate services are intermediaries. As shown in Figure 2-5, the credit service receives a request from the loan service and then forwards the request on to the credit bureau services for each of the major credit bureaus. This allows the user’s credit information to be checked by multiple sources while allowing the loan service to use a single service. As part of its calculations, the rate service may wish to make a request to a Web service that provides the current Treasury bonds rate.

Figure 2-5. The Loan Service and Its Intermediaries

When multiple requesters, providers, and intermediaries are participating in a Web service transaction, it may be necessary to coordinate them. There are two different types of mechanisms for coordinating Web services: Web services orchestration and Web services choreography. Web services orchestration is performed within an organization’s SOA and concerns the use of existing Web services to create another Web service. Web services choreography is performed among multiple organizations’ SOAs and describes relationships between Web services so that Web services understand how to interact with one another to perform a process. Figure 2-6 illustrates how no single Web service is in control in a choreography.

Figure 2-6. A Web Service Choreography

When invoking a Web service orchestration, the encapsulating Web service uses an orchestration engine to define which Web services will be invoked. In contrast, when invoking a Web service choreography, the sequence of Web services is more dynamic, and the decisions are made by the relationships defined between individual Web services rather than by a unifying orchestration engine. Figure 2-7 illustrates how the Web service orchestration is controlled by a single Web service.

Figure 2-7. A Web Service Orchestration

Using the loan service example, the credit service could be implemented as a choreography. Each Web service in the transaction is not necessarily operated by the same organization as the credit service. Each Web service, the credit service and the individual credit bureau service, would enumerate the rules and expectations for interacting with one another. The credit service would dynamically look up the credit bureau service, process the information that is needed to interact with it, and then initiate a choreography among the services.

The rate service may be implemented as an orchestration, as all of the involved Web services would be internal to the rate service’s organization. To fully calculate the interest rates that the loan service will use, the rate service consists of a chain of SOAP requests and responses passed from one internal Web service to another to gather the necessary information to respond with accurate rates. Each transaction within the orchestration is controlled by the rate service, so that requests and responses occur in the proper order and failures do not propagate throughout the transaction. Once complete, the rate service returns the result of the orchestration to the loan service, as shown in Figure 2-8.

Rate Service

Internal Rate

Internal Rate

Service

Service

2

Internal Rate

3

Service 1

Figure 2-8. The Rate Service as an Orchestration

Because a Web service relies on some of the same underlying HTTP and Web-based architecture as common Web applications, it is susceptible to similar threats and vulnerabilities. Web services security is based on several important concepts, including¹¹:

Identification and Authentication: Verifying the identity of a user, process, or device, often as a prerequisite to allowing access to resources in an information system.

Authorization. The permission to use a computer resource, granted, directly or indirectly, by an application or system owner.

Integrity. The property that data has not been altered in an unauthorized manner while in storage, during processing, or in transit.

Non-repudiation. Assurance that the sender of information is provided with proof of delivery and the recipient is provided with proof of the sender’s identity, so neither can later deny having processed the information.

Confidentiality. Preserving authorized restrictions on information access and disclosure, including means for protecting personal privacy and proprietary information

Privacy. Restricting access to subscriber or relying party information in accordance with Federal law and organization policy

The Web services security dimensions have been defined as: secure messaging, resource protection, negotiation of contracts, trust management, and security properties¹². These dimensions encompass the elements of security (discussed in Section 2.2) in a Web services environment. Each dimension is essential to the development of secure applications using Web services, but each dimension affects a different layer of the Web service. This section describes each security dimension and provides an overview of what technologies are available, what is on the horizon, and what remains to be done.

Web services rely on the Internet for communication. Because SOAP was not designed with security in mind,¹³ SOAP messages can be viewed or modified by attackers as the messages traverse the Internet. There are several options available for securing Web service messages:

HTTP over SSL/TLS (HTTPS). Because SOAP messages are transmitted using HTTP, it is trivial to modify a Web service to support HTTPS.

XML Encryption and XML Signature. These XML security standards developed by W3C allow XML content to be signed and encrypted. Because all SOAP messages are written in XML, Web service developers can sign or encrypt any portion of the SOAP message using these standards, but there is no standard mechanism for informing recipients how these standards were applied to the message.

WS-Security. WS-Security was developed to provide SOAP extensions that define mechanisms for using XML Encryption and XML Signature to secure SOAP messages.

Each secure messaging option has its own strengths and weaknesses. They are discussed in more depth in Section 3.6.

When resources are made publicly available, it is important to ensure that they are adequately protected. Usually, Web services are intended to be accessible only to authorized requesters, requiring mechanisms for access control. To perform access control, Web services need to identify and authenticate one another. Several different methods are available, including transport layer authentication, token authentication via the WS-Security specification using SAML assertions or other tokens, and the SOAP authentication header. Authorizations for Web services are often done through custom implementations, but the XACML is an OASIS standard available for performing authorization decisions, eliminating the time and cost associated with developing and testing a custom solution.

In the loan service example, the rate service is a provider service. When the rate provider receives a request, it needs to validate the identity of the requester and the supplied input. By validating the requester’s identity, the rate service can check with organizational policies to determine whether the requester is authorized to access rate information. By validating the input, the rate service can ensure that the request includes valid and acceptable parameters. If the requester submits unexpected content, it is reason to suspect that an attacker may be probing the Web service for vulnerabilities. Once the request has been processed, the provider sends an appropriate response containing the bank’s current rate information.

The challenges faced in protecting resources go beyond simply providing access control mechanisms. The goal of an attacker may not be simply accessing the Web service. Rather, the attacker’s objectives may include disrupting the service, acting as a man-in-the-middle, eavesdropping on the service, impersonating the service, or even using weaknesses in the service’s implementation to control the host platform. Typical threats to Web services are discussed in more detail in Section 2.6.

One of the primary goals of SOA is to facilitate the automation of business processes by allowing services to automatically discover one another and immediately take advantage of the functionality offered. To facilitate business transactions, Web services need to be able to create, enforce, and abide by contracts between organizations. For example, a credit service relies on another organization’s Web services. A contract between the two organizations ensures that all Web services will operate as expected and that the information passed between organizations will be properly secured. In many situations, these contracts are negotiated and agreed upon by the organizations before implementation can begin. Ideally, Web services would be able to negotiate and agree upon such contracts electronically, immediately after discovery during runtime to take advantage of new functionality immediately. Negotiating such contracts electronically opens up a number of potential legal ramifications for the organizations involved. Therefore, in lieu of this ideal, many SOAs rely on an implicit contract offered by the WSDL interface of a Web service and expect it to operate as advertised.

The ebXML¹⁴ suite of standards provides tools for negotiating business processes and contracts using Web services. However, ebXML was developed as a replacement for Electronic Data Interchange (EDI) and, as such, is often considered too complex to use for regular Web services. Because ebXML Web services rely on SOAP, portions of the ebXML standards may be individually adopted for small organizations. Usually, the WSDL interface or registry entry of an individual Web service can be considered an implicit contract between the services, but there are no standards that support the enforcement of implicit contracts. Research in the realm of Web service choreography will aid in enforcing implicit contracts.

Web services may have specific QoS or QoP requirements. For example, a credit service may require that certain information be encrypted and signed using WS-Security, while the requester service may require a guaranteed response through reliable messaging. The ebXML suite of standards provides support for security properties in contracts, but it does not fully support automatic security properties negotiation. The WS-Choreography standard provides some support for negotiating security requirements. A promising area of research is Semantic Web services. Using Semantic Web technologies, Web services can intelligently search for other Web services with specific properties, including security properties. In addition, the Semantic Web Services Architecture (SWSA)¹⁵ developed by the Defense Advanced Research Projects Agency (DARPA) Agent Markup Language (DAML)

Program specifically addresses negotiating contracts among Semantic Web services and the associated architectural requirements:

Negotiation protocol. Web services require a protocol for negotiating properties of the transaction. Research is underway to develop negotiation protocols using Semantic Web technologies.

Negotiation service. To facilitate negotiation, a provider that allows other services to offload negotiation can serve as a core service within the SOA.

Mediation service. Services involved in negotiation may need to have disputes over various properties of the service contract mediated by a trusted core service.

Auditing service. The resulting contract between services will need to be stored for non-repudiation services by a trusted core service.

Negotiation-enabled Web service. Individual Web services will be able to inform one another that they support negotiation through the discovery process.

While these architectural requirements are specific to SWSA, these functions can prove useful when developing any SOA capable of supporting negotiation.

Web services standards are inherently flexible and have allowed several architecture models to evolve: a brokered trust model, a pairwise trust model, a federated trust model, and a perimeter defense model. While these models use the term trust, they are limited to being able to trust the identity of the service. Being able to establish a Web service’s identity does not mean that the service itself is inherently trustworthy. There is always the possibility that a Web service has entered an erroneous state or has been compromised.

In their 1996 paper, McKnight and Chervany defined trust as “the extent to which one believes (and feels confident in believing) that the other person is trustworthy in the situation.”¹⁶ Based on this definition, authenticating the identity of a Web service may not be sufficient when determining whether or not to trust a remote Web service. When trust relationships span multiple organizations, the requirements for individual Web services will vary. For this reason, regardless of whether the provider is a trusted entity in terms of its identity, the requester should not presume that it will not send erroneous or potentially malicious content in a response to the requester’s request. Similarly, because providers listen (like a server) for requests from various requesters, they should not presume that erroneous or malicious content will not be sent in place of valid requests. Nevertheless, identifying and authenticating Web services is an essential step in establishing trust. Each trust model provides different benefits and drawbacks, allowing trust to be supported in a wide variety of environments. With this caveat on the definition of trust in a Web services environment, the remainder of this document uses the term trust when discussing authentication to maintain consistency with standards and research papers.

The pairwise trust model is the simplest of all trust architectures, but the least scalable. In the pairwise architecture, each Web service is provided—at configuration—the security information of all other Web services that will be interacted with so that those transactions and Web services can be trusted. This approach eliminates the need for developers to coordinate with other entities, but it creates an unscalable and non-uniform security architecture because adding a new Web service would require adding new information to all existing services it could interact with. When the SOA becomes large and dynamic, adding a new service can become time and resource intensive.

In the brokered trust model, an independent third party acts as a trusted third party (TTP) for the Web service. The requester and provider interface with the third party for a variety of security services. Unlike the pairwise trust model, Web services using the brokered trust model need to be designed with the broker’s interface in mind, so that identity information can be properly retrieved by the Web service. This approach eases the distribution of identity information between Web services; each Web service will only need to verify the identity of the trust broker rather than the identity of all Web services in the SOA.

A federated trust model allows Web services from different organizations to seamlessly interact with one another via various federation mechanisms. It builds upon both the brokered and pairwise trust models by allowing organizations to use their own central trust brokers while relying on pairwise trust or brokered trust between organizations. Each organization that wishes to federate must do so following complex business procedures and protocols, but the end result allows the Web services of each organization to interact with few or no changes to their original configuration.

Another commonly used Web service architecture is the perimeter defense strategy. Devices known as XML gateways are placed between providers and requesters. An XML gateway acts as a proxy for the Web service by performing the security-related functionality in its place. Although XML gateways are useful tools in an organization’s security strategy, they are not a panacea. Should an attacker bypass the XML gateway, all internal Web services will be vulnerable to attack. Internal Web services must be designed, developed, and configured securely.

All software, including Web services, needs to satisfy requirements for performance, cost, usability, and security. Examples of possible requirements for secure software are predictability, correctness, and availability.

Several organizations, including OASIS, W3C, the Liberty Alliance, and various members of industry have put together numerous security standards and techniques for securing Web services. For the most part, these standards and techniques all complement or extend one another, but there are some conflicting or competing standards. This section provides an overview of the various standards and how they can be used to meet security requirements and protect against threats to Web services. Section 3 discusses the most widely accepted standards, technologies, and techniques in detail.

The open standards communities that created Web services developed a number of security standards for Web services. Figure 2-9 illustrates a notional reference model for Web services security standards. This reference model maps the different standards to the different functional layers of a typical Web service implementation. These layers are modeled after the OSI Reference Model but are not intended to be interpreted as strictly hierarchical.

Figure 2-9. Web Services Security Standards: Notional Reference Model

Standards at the network, transport and XML security layers are used to secure messages as they are transmitted over the network. The security standards IPsec, SSL/TLS (Secure Sockets Layer/Transport Layer Security), XML Encryption and XML Signature each operate on SOAP messages at a different level.

Above the XML Security layer, there are two types of standards: standards built on top of SOAP and standalone standards. Message security standards WS-Security and WS-SecureConversation define how to use XML Signature, XML Encryption and credentials to secure SOAP at the message layer while reliable messaging standards define the protocols and constructs necessary to ensure that messages will be received. The access control standards are not unique to Web services; XACML can define the access policy for any system and SAML can be used to define assertions in any environment. The policy layer’s WS-Policy defines a grammar to communicate the policy requirements of a Web service. These standards are described in more detail in Section 3.

Security management specifications define other Web services to manage credentials such as PKI certificates within the SOA. Identity management standards take advantage of access control standards, policy standards and SOAP standards to offer services for distributing and managing user identities and credentials within the SOA.

Table 2-1 shows which security requirements are satisfied by the various specifications and standards.

Table 2-1. Specifications and Standards Addressing Security of SOAs

Each SOA security dimension has one or more security requirements. Each requirement may have any number of standards that support it. For example, both SSL/TLS and WS-Security provide confidentiality, integrity and authentication support for the messaging dimension, while the accountability requirement of the resource protection dimension does not have any supporting standards.

The notion of core services has yet to be completely defined. Traditionally, these are services that can be used by any of the Web services in an organization’s SOA. Two examples are the Open Grid Services Architecture (OGSA), developed for the Globus Grid, and the Department of Defense’s (DoD’s) Net-Centric Enterprise Services (NCES), developed for the Global Information Grid. Both OGSA and NCES provide a set of services available throughout an organization that are commonly used or essential to most Web services, such as discovery, authentication, and authorization. OGSA provides a comprehensive list of what can be offered as core services: service management, service communication, policy services, and security services. Most SOAs use these same categories of core services but may provide differing names:

Service management services: assist in managing a SOA by providing mechanisms to install, maintain, monitor, and troubleshoot Web services.

Service communication services: provide support for various types of communications models between services: queued messaging, publish-subscribe event notification, and distributed logging services.

Policy services: provide a framework for creating, administering, and managing policies for the infrastructure; these policies cover security, resource allocation, and performance.

Security services: provide support for different security models, mechanisms, protocols, and technologies that extend core Web services security protocols to support activities such as authorization, authentication, trust policy enforcement, and credential transformation.¹⁷

Authentication

Rate

Core Web Service

Web Service

Loan Web Service

Authorization Core Web Service

Identification Core Web Service

Figure 2-10. Core Services Used by the Loan Service

In the loan service example, shown in Figure 2-10, core services are used to offload identification, authentication, and authorization, among other capabilities, so that developers of the loan, rate, and credit services do not have to implement their own security functionality. For instance, when the loan service makes a request, it first retrieves an identifier from the identification service associated with the subject. When the rate service receives the request, it uses the authentication service to validate both the subject and the loan service. If authentication is successful, the rate service queries the authorization service to ensure the loan service and subject are authorized to receive policy information.

By offloading some of the processing to these core services, the implementation of the loan, rate and credit services is simplified when compared to a single Web service with similar functionality. This further improves security by lowering the number of possible defects that could exist in the individual services, but it introduces a slight performance penalty associated with the communication with the core services. Core services may also introduce a single point of failure in the SOA.

Security decisions must always be made with an understanding of the threats facing the system to be secured. While there are a wealth of security standards and technologies available for securing Web services, they may not be adequate or necessary for a particular organization or an individual service. For that reason, it is important to understand the threats that face Web services so that organizations can determine which threats their Web services must be secured against. According to WS-I, the top threats facing Web services are:¹⁸

Message alteration. An attacker inserts, removes or modifies information within a message to deceive the receiver

Loss of confidentiality. Information within a message is disclosed to an unauthorized individual

Falsified messages. Fictitious messages that an attacker intends the receiver to believe are sent from a valid sender

Man in the middle. A third party sits between the sender and provider and forwards messages such that the two participants are unaware, allowing the attacker to view and modify all messages

Principal spoofing. An attacker constructs and sends a message with credentials such that it appears to be from a different, authorized principal

Forged claims. An attacker constructs a message with false credentials that appear valid to the receiver

Replay of message. An attacker resends a previously sent message

Replay of message parts. An attacker includes portions of one or more previously sent messages in a new message

Denial of service. An attacker causes the system to expend resources disproportionately such that valid requests cannot be met.

The importance of these threats may vary depending on an organization’s needs and purpose. In some instances, messages need not be kept confidential, so loss of confidentiality is not a concern. Similarly, organizations may offer a Web service to the public. For example, a Web service that provides information about the current weather forecast need not be concerned if a request is from a falsified sender. Regardless, it is important to understand these threats and what technologies are available to mitigate them.

The following Web services and HTTP standards can protect against many of these threats:

W3C XML Encryption. Used by WS-Security to encrypt messages and provide confidentiality of part or all of a SOAP message

W3C XML Signature. Used by WS-Security to digitally sign messages and provide message integrity and sender authentication

WS-Security Tokens. Allows messages to include credentials to aid receivers in determining whether or not the message sender is authorized to perform the requested action. Supported token types include:

W3C WS-Addressing IDs. Allows the message sender to supply a unique identifier for the message

IETF SSL/TLS. Secures the HTTP protocol over which SOAP messages are sent and received

SSL/TLS with client authentication. Requires both the sender and receiver to authenticate with one another before securing the HTTP protocol

IETF HTTP authentication. Allows usernames, passwords (via HTTP Basic) or password digests (via HTTP Digest) to be sent as part of the HTTP header.

These technologies, along with other technologies that support them, are discussed in-depth in Section 3. Table 2-2 illustrates which standards provide protection against these threats. As the table shows, SSL/TLS and WS-Security, through XML Encryption and XML Signature, provide similar protections against threats; Section 3.6 discusses SSL/TLS, WS-Security and WS-SecureConversation and the trade-offs associated with each technology.

Table 2-2. Threats Addressed by Current Web Service Standards

* Threat mitigated only for provider messages to requester, not for requester messages to provider.

As shown in Table 2-2, there are no standards that protect against DoS attacks. While the OASIS WS-Reliability standard and the work produced by the OASIS WS-RX technical committee address message reliability, ensuring the availability of Web services remains a hard problem. Many of the availability techniques used by high volume Web applications, such as load balancing, clustering and replication, can be used to aid in preserving availability.

Web services also face threats associated with all software: defects in a Web service implementation may lead to exploitable vulnerabilities. Web services, like Web applications, are remotely accessible, so attackers can take advantage of the Web service’s availability to probe it for potential exploits. As with any remotely accessible service, it is important that Web services be implemented securely and that traditional network security tools and techniques be used to limit access to the Web service to only those networks and systems that should have legitimate access. Some aspects of secure Web service development are discussed in Section 6.

As a software-based service that is network-enabled, Web services are at risk for many of the same security exploits that target any other software. An extensive listing and descriptions of common attacks targeting Web services appear in Appendix A.

Traditional security technologies are by and large inadequate to secure Web services. Perimeter-based network security technologies (e.g., firewalls, IDS) are inadequate because Web services are transmitted using HTTP, which is usually given free reign by firewalls, and SOAP may not be supported by an organization’s IDS. While certain types of firewalls support filtering HTTP content, and some can support filtering SOAP, filtering all XML messages with traditional firewalls can prove to be expensive and reduce the throughput of the firewall. Due to the SOA paradigm, which allows for messages to be passed via intermediaries rather than simply by point-to-point communication, SSL/TLS is inadequate for a number of possible SOAP transactions because SSL/TLS is designed to secure transactions between individual Web services—and will not protect against an intermediary performing a man-in-the-middle attack. The SOAP specification explains that SOAP was designed with the intent of leaving security for an extension:

“Two major design goals for SOAP are simplicity and extensibility. SOAP attempts to meet these goals by omitting, from the messaging framework, features that are often found in distributed systems. Such features include but are not limited to ‘reliability’, ‘security’, ‘correlation’, ‘routing’, and ‘Message Exchange Patterns’ (MEPs). While it is expected that many features will be defined, this specification provides specifics only for two MEPs. Other features are left to be defined as extensions by other specifications.”¹⁹

WS-I has produced a document describing SOAP’s security challenges, which include the following:

SOAP does not perform any authentication between SOAP endpoints or intermediaries, so there is no way to verify the origin of a SOAP message.

SOAP does not provide a mechanism for ensuring data integrity or confidentiality either at rest or during transit.

SOAP does not provide a mechanism for detecting resubmitted SOAP messages.

The WSDL description of a Web service is usually automatically provided by the Web service framework used (e.g., appending ?wsdl to the Web service URI will return its WSDL) and may openly reveal the entire API of the Web service—even parts of the Web service that may have been disabled or that are used solely for debugging purposes.²⁰ Exposing too much information about a Web service through its WSDL descriptor may provide information about the design and security requirements of the Web service.

UDDI registries openly provide details about the purpose of a Web service as well as how to access it. In particular, UDDI provides tModels (described in Section 3.9.1) as “a way to mark a description with information that designates how it behaves, what conventions it follows, and what specifications or standards the service complies with.”²¹ Attackers may use this information to find potential flaws in the Web service. For example, the UDDI entry may show that the Web service uses a vulnerable specification. Any information in excess of that required to bind to the Web service may benefit an attacker.

Additionally, Web services use UDDI registries to discover and dynamically bind to Web services at run time. Because the UDDI specifications did not address digitally signing entries until version 3.0.2 (released as an OASIS standard in 2005), many UDDI registries do not provide a robust mechanism for verifying the authenticity of registry entries. This may allow malicious Web services to be added to the registry and used by other Web services.

Because much of Web services security relies on XML Encryption and XML Signature or SSL/TLS, all of which use X.509 digital certificates to store cryptographic keys, most Web services frameworks seamlessly support and interface with a PKI. In particular, WS-Security supports the X.509 Certificate Token Profile. While the Web service itself does not need to implement XKMS or non-XML PKI protocols, PKI protocols should be supported by the host system to properly interact with the PKI.

In general, .NET and Java Web services rely on Windows and Java mechanisms, respectively, to store the various certificates that will be used by the Web service. By default, these key storage mechanisms require administrative interaction to fully interact with a PKI. Commercial off the shelf (COTS) products are available to integrate with a PKI. Additional Web services can also be developed to interact with the key management infrastructure.²²

Web services frameworks provide support beyond simply abstracting the technical SOAP implementation. They often provide authentication and authorization services. Java Enterprise Edition (Java EE) and .NET both provide client authentication via SSL/TLS as well as sophisticated authorization services that can interface with any authentication mechanism. In particular, frameworks use widely used and robust libraries for authentication and authorization, which make these implementations less likely than others to have bugs. An additional security feature provided by Java and .NET frameworks is sandboxing, which is designed to separate all actions of the Web service from the operating system. Sandboxing affords added benefits to developers and administrators: stricter permissions and capabilities than those provided by the operating system can be applied to a Web service, and the sandbox helps to prevent the Web service from inadvertently or maliciously harming the underlying operating system, providing the sandbox itself is robust against attack.

Web services frameworks provide a number of benefits to developers in addition to well-tested tools and libraries: automatic creation of WSDL descriptors, client and server stubs, and potentially some implementation code. While this support can greatly improve the productivity of the development team, some developers may begin to rely on these tools when developing Web services and may not fully understand the code that is automatically generated. Should such developers be required to use a different development environment for Web services, they may not be adaptable and may inadvertently introduce security vulnerabilities. Additionally, the use of non-vetted, automatically generated code can itself lead to security vulnerabilities; most automatically generated code is intended merely to guide and aid developers, not for production use.

Developers need to be fully versed in the libraries supported by the framework when dealing with libraries that perform authentication, authorization, and other security functions that are not supported by the base framework. For example, XACML and SAML provide a flexible and platform-independent framework for distributed authorization. To properly implement XACML and SAML support may require overriding the framework’s authentication mechanism at various points, which could lead to potential vulnerabilities in the Web service application. Supporting SAML or WS-Security in place of native authentication mechanisms may require the Web service to bypass authentication services provided by the framework, leading to potentially vulnerable code. Until frameworks provide native support for platform-independent authentication and authorization mechanisms, there will always be the potential for custom-developed code to be inadequately robust and lead to potential security breaches.

This section introduced the underlying concepts of Web services and the security challenges they face. The challenges have five dimensions:

Secure messaging. Ensure that SOAP messages traversing networks are not viewed or modified by attackers. WS-Security and WS-SecureConversation provide the confidentiality and integrity services necessary.

Protection of resources. Ensure that individual Web services are adequately protected through appropriate identification, authentication, and access control mechanisms. There is a plethora of standards available for controlling access to Web services.

Negotiation of contracts. To truly meet the goals of SOA and automate business processes, Web services should be capable of negotiating business contracts as well as the QoP and QoS of the associated transactions. While this remains a hard problem, standards are emerging to address portions of contract negotiation—particularly in the QoP and QoS field.

Trust management. One of the underlying principles of security is ensuring that all entities involved in a transaction trust one another. To this end, Web services support a variety of trust models that can be used to enable Web services to trust the identities of entities within the SOA.

Security properties. All Web service security processes, tools, and techniques rely on secure implementation. A vulnerable Web service may allow attackers to bypass many—if not all—of the security mechanisms discussed in Section 3.

To adequately meet the challenges posed by each security dimension, the Web services community has developed a large number of standards. Each standard meets a different security challenge faced by Web services. WS-Security and SSL/TLS, for example, address the secure messaging domain, while WS-Federation and Liberty Identity Federation Framework (IDFF) address the trust management domain. Some security domains, such as messaging and trust management, are addressed by competing or overlapping standards, while others, such as the security properties domain, require further research within the community to fully address the challenges faced. Some standards address relevant security properties. For example, WS-Reliability and WS-ReliableMessaging provide some QoS functionality, allowing guaranteed message passing even if the network is under attack. More standards and technology are necessary to provide full support for all of the necessary security properties. When determining which Web services standards and technologies to adopt, it is important to be aware of the threats facing an organization’s Web services and prioritize them to ensure that resources are distributed appropriately for the Web services being secured.

Web service security standards, functions, and technologies continue to evolve at a rapid pace, driven by changes in the types of software attacks, community stakeholders, and Web services policy decision makers. This section describes several current and emerging standards, initiatives, and techniques aimed at improving the security of Web services. Many of the concepts used in securing Web applications are useful for understanding the security of Web services. Several resources on the subject of Web application security are provided in Appendix F for further reference.

Authentication is required to limit access to resources, to identify participants in transactions, and to create seamless personalization of information based on identity. A means of sharing the fact that authentication has been performed successfully is necessary to support single sign-on, allowing users to authenticate with one system and use other services and applications within a SOA.

Service-to-service authentication can be performed using a variety of methods, from HTTP-based token authentication to SSL/TLS-certificate based authentication, or by passing tokens along with the SOAP request. The HTTP and SSL/TLS-based methods are performed below the SOAP message layer and are transparent to the Web services involved, while SOAP-based token protocols require interaction between Web services.

Token-based Web services authentication is usually performed using the OASIS WS-Security standard, which supports tokens based on a variety of authentication standards: usernames, X.509 PKI certificates, Kerberos tickets, or SAML assertions (SAML is discussed in-depth in Section 3.5.3). WS-Security libraries are available for most of the widely used Java and .NET Web services development platforms. When a service provider attempts to access a remote Web service on behalf of a user, it should send an authentication token within a WS-Security message. These tokens convey that the initiating entity (e.g., a user or requester) has been authenticated and provide information about the entity, such as the authentication mechanism, time, and possibly subject attributes that may be applicable. Often, these tokens take the form of a SAML assertion.

For authenticating Web services between organizations using identity federation, the Liberty Alliance developed Liberty ID-WSF, which supports service-to-service authentication based on pairwise trust and federated identity. Federated authentication can also be performed using the WS-Trust and WS-Federation specifications developed to support WS-Security. Web service authentication using SAML and WS-Security is described in the following section. Identity federation technologies are discussed in-depth in Section 3.2.

Sometimes, a service provider may not be able to perform the actions that a user or requester wishes it to perform, but it knows of a remote Web service that can. The service provider may invoke another remote service to satisfy the requester’s request, which is known as service chaining. The service provider may use a SAML assertion, a WS-Security message, or both to make certain that both Web services trust each other.

There are two different approaches to service chaining. The Web service can access the remote Web service either as itself or by taking on the identity of the originator of the request. In the first case, the two Web services would communicate with each other as normal. In the second case, the remote Web service needs to be provided the identity of the originator in a trusted fashion. This can be satisfied using WS-Security and SAML.

There are two ways to pass the identity of the originator on to a remote service. First, if the Web service received a SAML assertion with the originator’s request, that SAML assertion can be passed on to the remote Web service. It may be necessary for the requester service to sign either the SAML assertion or the SOAP message so that its own identity is passed to the remote service as well. Another option is for the requester service to generate and sign a SAML assertion for the originator itself and pass this SAML assertion on to the remote Web service. In this type of configuration it is not possible for the remote Web service to determine who originally requested the information. This limitation may be a hindrance in chain of trust deployments, as the chain is limited to the last requester.

By contrast, if the originator’s SAML assertion is used or is signed, it is possible to trace the request back to the requesting entity. By forwarding a SAML assertion to the remote Web service, the requester service is able to assert the identity of the originator of the request. By either signing the SOAP message using WS-Security or the SAML assertion, the remote Web service is provided with the identity of the requester and can then determine whether or not it will trust the SAML assertion provided. If the authentication information requires confidentiality, SSL/TLS or WS-Security’s encryption functionality should be used.

The use of signed SAML authentication or authorization assertions should be approached with caution. A signed SAML assertion is a token that can be reused by an attacker or a malicious service. Care must be taken to ensure that timestamps and validity periods are used and enforced. To address this, SAML assertions can be cryptographically bound to individual SOAP messages by signing the parent tag of the SAML assertion (e.g., using WS-Security to sign the Security element rather than the contained SAML token). While the SAML assertion may be reused, it will be invalid unless the entire signed portion of the message is also re-used, making it easier for service providers to detect replay attacks.

Many Web services rely on the authentication mechanisms provided by HTTP and SSL/TLS. These solutions are only acceptable over a direct connection between two SOAP endpoints. If a SOAP message is to travel between multiple SOAP endpoints before reaching its destination, it is not acceptable to rely on HTTP and SSL/TLS for authentication, confidentiality, and integrity. There is no guarantee in this type of configuration that one of the Web services that handled the message did not misuse or store the data. In 2002, Microsoft, IBM, and Verisign released the WS-Security specification to address this shortcoming. In 2003, WS-Security was submitted as an OASIS standard, and in 2004 it was released as an OASIS standard. The ability of WS-Security to provide authentication (as well as confidentiality and integrity) at the SOAP message level is important for Web services to trust the messages they receive.

Authentication in WS-Security is performed by including claims in the WS-Security header of a SOAP message. Claims provide information about the identity of the SOAP message sender which can then be used to determine whether or not the sender is authorized to access the resources requested. Claims can either be endorsed or unendorsed. An endorsed claim, such as an X.509 certificate, provides inherent proof that the sender is the entity referenced, because the key referenced in the X.509 certificate can be used to verify the signed portion of the SOAP message. An example of an unendorsed claim is a username/password pair or a SAML assertion. In an unendorsed claim, there is no inherent method for determining that the sender of the SOAP message is the entity that the header specifies.

WS-Security also provides mechanisms for encrypting and signing elements of a SOAP message, including any WS-Security tokens. WS-Security explains how to use the XML Security and specifications within SOAP messages and what headers and elements are necessary to correctly process the ciphertext.

There are several concerns prevalent in a WS-Security compliant Web service. Many of these concerns are not specific to WS-Security and apply to message integrity and confidentiality mechanisms in general.

WS-Security can be susceptible to replay attacks. An attacker may be able to reuse a WS-Security packet that is recorded. To mitigate this problem, timestamps, sequence numbers, and expirations should be sent signed within the WS-Security message. The receiving endpoint should then check to make sure that the message received has not been replayed.

WS-Security provides support for tokens that can be sent in the WS-Security header of a SOAP message. Without proper safeguards, these security tokens can be substituted. It is important when using WS-Security tokens to sign the appropriate portions of the message. WS-Security headers that are signed by the sender can be used to detect alterations.

Credential management may be a concern with WS-Security. PKI is most commonly deployed using X.509 certificates. PKI is used in e-commerce for performing SSL/TLS transactions over the World Wide Web. In many security architectures, user credentials are presented in the form of X.509 certificates. To this end, XML protocols and Web services security protocols have been developed to work with PKIs and X.509 in particular. XML Encryption can use a PKI for encrypting XML messages while XML Signature relies on a PKI for digitally signing XML content using algorithms similar to those defined in FIPS 186-223. As such, Web services innately support working within a PKI. Management of X.509 certificates and other credentials may or may not be provided by the SOA. While SOAP-compliant services exist to interact with a PKI (e.g., XKMS), most installed PKIs use older non-XML-based protocols which require certificate management to take place out-of-band from XML-based communication.

Most WS-Security, SAML, and XML Security libraries do not perform full certificate validation by default. All certificate libraries will validate to make sure that the certificate was signed by a trusted Certificate Authority (CA). Most certificate libraries are not configured—and may not adequately support—checking the certificate against the CA’s Certificate Revocation List (CRL) or the Online Certificate Status Protocol (OCSP), the two main standards for detecting whether or not a certificate has been revoked. To support the more advanced features of PKI certificate management, either additional libraries or appropriate versions of the Web services framework should be used. For example, newer versions of Java (1.5+) support OCSP, and Microsoft’s Windows XP and Windows Server 2003 support OCSP for .NET-based Web services. For some applications, they may need to interact explicitly with the CRL or OCSP responder through some API to fully use PKI certificate management. Some PKI libraries, however, will perform CRL or OCSP checking automatically when validating digital signatures. The use of CRLs, OCSP, and PKI authentication is described in more detail in FIPS 19624, NIST SP 800-3225 and NIST SP 800-2526.

Attribute management can also be a concern with WS-Security. With the availability of SAML, many Web services may use Attribute Based Access Control (ABAC), which allows users to be authorized based on their attributes rather than their roles or user IDs. Attributes can include a user’s role, location, nationality, organization or clearance. Attribute management is important even without ABAC, as Web services may require information about various entities during the course of a Web service transaction.

Identity management for SOA encompasses the full range of identity-related events, information, and documents by which an entity’s identity is verified, identity documents and credentials are issued to the entity, and entity identities are authenticated at point of entry into the SOA. In the SOA, an entity’s identity forms the basis for both authorization and trust.

An Identity Management System (IDMS), such as that pictured in Figure 3-1, is responsible for verifying the identities of entities, registering them, and issuing them digital identifiers. In accordance with Homeland Security Presidential Directive (HSPD) 12, Subject: Policy for a Common Identification Standard for Federal Employees and Contractors²⁷, NIST Federal Information Processing Standard (FIPS) 201-1, Personal Identity Verification of Federal Employees and Contractors²⁸, describes a number of requirements that must be satisfied before a human entity may be registered in a Federal IDMS, including a National Agency Check and Inquiries (NACI) background check. Non-government organizations may have different rules for registration. For example, users who wish to gain access to many e-commerce sites often need to provide only a valid email address and a credit card number.

Figure 3-1. Identity Management Overview

Once an entity has been issued a digital identifier, that identifier can be used within that organization to associate other information with the entity, such as role and authorization attributes. The identifier may also become part of the digital credential that authorizes the entity to access different resources in the SOA.

Once registered, an entity must provide a portion of its credentials sufficient to authenticate that entity’s identity. Again, different organizations have different policies for what constitutes sufficient authentication credentials. Many e-commerce sites require the entity to supply a username and password; other organizations may require the entity to submit an X.509 certificate.

After the entity’s identity has been authenticated, the policy decision point (PDP) of the system or resource to which it desires access must determine whether the now-authenticated entity is also authorized to access the resource. To perform authorization, the PDP relies on privilege management and attribute management. Privilege management enforces the policies that govern entity access. The policy decision to allow or deny access may be based on a single entity attribute such as the entity’s role, or it may require a combination of fine-grained attributes such as the physical location of the entity, its currently active role in the system, and its clearance level. The attribute management system uses the entity’s digital identifier (issued by the IDMS) to locate and retrieve those of the entity’s attributes that are required by the privilege management policy.

There are three major identity architectures²⁹ available for use in Web services:

Isolated identity management. Isolated identity management is the architecture used by most Web applications on the Internet. In isolated identity management, service providers act both as a credential provider and identity provider. This simplifies management for a single service and negates the need for a TTP to handle either the credentials or providers. The drawback for an isolated identity management system is that every service must know the credentials and identifiers for all authorized requesters. In a large SOA, administering each provider may become unmanageable.

Federated identity management. In identity federation, a group of providers agrees to recognize user identifiers from one another. Each service provider acts as a credential and identity provider for a subset of requesters. By issuing assertions (e.g., SAML authentication and attribute assertions), a service provider can supply other providers with the necessary information about the requester without requiring the requester to authenticate a second time. This simplifies identity and credential management for the SOA as a whole, but requires individual services to be aware of and trust assertions from one another. In a single enterprise-wide SOA, it may not be difficult for providers to trust one another, but they may be less willing to trust assertions when the SOA includes providers from different organizations. A requester in the SOA may make a request to a provider and supply an arbitrary assertion to gain access. In identity federation, it is important to develop organizational policies appropriate for the types of data that traverse the SOA.

Centralized identity management. In centralized identity management, providers rely on a single TTP to provide credentials and identifiers to requesters. Centralized identity management is similar to federated identity management in that the identity and credential providers supply assertions directly to service providers, allowing requesters access without authenticating a second time. In this architecture, individual service providers need only be aware of the identity provider. In a cross-organizational SOA, organizations may be willing to trust another organization's identity providers more than individual services. A major drawback of the centralized identity management architecture is that the identity providers may act as a single point of failure. Should all of an organization's identity providers suffer a DoS, it will not be possible for providers to accept any requests.

When developing a new SOA or updating an existing SOA, it is important to consider the size of the SOA and the organization's priorities. One or more of these architectures may not be suitable for SOAs of a certain size or may violate organizational policies.

In May 2005, Kim Cameron, Identity and Access Architect at Microsoft, authored The Laws of Identity 30 based on his research into the requirements for a unified identity metasystem, a system of identity systems that exposes a unified interface for disparate underlying identity technologies. Organizations that follow these laws when developing or deploying an identity management architecture will be able to better support cross-organizational collaboration. The seven laws are as follows:

User Control and Consent. Identity systems must not reveal identifying information without the user's consent.

Minimal Disclosure for a Constrained Use. Identity systems must disclose the least amount of identifying information while simultaneously limiting its use as much as possible.

Justifiable Parties. Identity systems must disclose identifying information only to parties having a justifiable need to know it.

Directed Identity. An identity system must support both omni-directional and uni-directional identifiers. An omni-directional identifier can be shared with any third party while a uni-directional identifier can only be used between two parties.

Pluralism of Operators and Technologies. An identity system must support multiple identity technologies and multiple identity providers.

Human Integration. The identity system must define the human user as a component of the distributed system.

Consistent Experience Across Contexts. The identity system must provide users with a consistent experience while enabling support for different technologies and providers.

Each of the major identity architectures discussed in Section 3.2.1 can be configured to follow these laws. By harnessing these laws, identity architectures can securely and adequately share identifying information amongst themselves so that large organizations or multiple organizations with differing policies and identity management architectures can better support a SOA.

Web services provide a standardized mechanism for communicating and sharing information across organizational boundaries. To maintain accountability and ensure that only authorized users gain access to restricted operations or information, Web services must be able to communicate identifying information across these organizational boundaries. According to Axel Buecker and Heather Hinton³¹, successful cross-organizational Web services require a way for providers to securely identify and provide services to authorized requesters and a way for requesters to securely invoke Web services with the necessary credentials.

Without an identity management framework, it becomes difficult for Web services to securely identify one another or provide recognizable credentials. For example, organization A may use X.509 certificates to identify Web services and individual users, while organization B may use Kerberos tickets for identification. If a requester from B sends a SOAP message with a Kerberos ticket to a provider from A, the provider will not be able to authorize the requester and will deny access. Identity management frameworks for Web services abstract this information and allow Web servers to securely identify one another regardless of the underlying identification technology. According to Buecker and Hinton, organizations need only develop a single set of Web services to facilitate Web service identity management across organizational boundaries:

Trust services. These services issue and validate authentication tokens for use across boundaries. Trust services can also exchange these tokens with a local identity provider.

Authentication and validation services. These services are provided by the local identity providers, granting tokens to authenticated users and validating tokens presented by a trust service.

Identity and attribute mapping services. Often included within the trust services, these services map supplied identifying information or attributes to their local equivalents.

User lifecycle management services. These services allow the establishment or mapping of identifying information and attributes for a user from a different organization.

Authorization services. Often implemented locally for individual services, authorization services can process the credentials provided by the sender, query the appropriate security policy and determine whether the sender is allowed to perform the requested action.

Identity management systems may provide these abstract services in various configurations, with some being explicit Web services while others are implicitly supplied. Should an organization choose to implement its own identity management architecture, it should determine which of these services are necessary and implement them accordingly.

For SAML or WS-Security to be useful on a large scale, trust relationships need to be established between remote Web services. A signed SAML assertion or WS-Security message is of no use if the receiver of the assertion cannot guarantee that the information asserted is trustworthy.

In the original SAML specification, only direct trust relationships are discussed—these are referred to as pairwise circles of trust. By contrast, SAML v2.0 provides two additional trust models for SAML: brokered trust and community trust.

Pairwise trust circles are the tightest and most direct form of trust relationship. Each entity that is authorized to communicate with another must share its key information. In a pairwise trust circle, if a SAML assertion can be verified, it is from an authorized entity. One major drawback of pairwise trust is that each entity must have a copy of the public key from every other entity with which it communicates, making the system inherently unscalable.

Brokered trust models are an extension of the pairwise trust model. When two services communicate that do not know each other’s keys, a TTP is used to exchange the key information for them. This scales better than the pairwise trust circle because adding a new service provider involves simply exchanging its key information with the TTP. The Web service providers have to trust that the TTP has not been compromised. This differs from the pairwise model in which each service provider is independently responsible for trust.

Another difficulty with the brokered trust model is that there may be a situation where the two services can communicate with the TTP but should not communicate with each other. In the pairwise model, entities that should not communicate with one another would simply not have the appropriate cryptographic keys to do so, preventing any messages from being passed. In the brokered trust model, each entity can communicate with the TTP and thus with other entities. Either the TTP or the individual entities must know who should and should not communicate with one another.

The community trust model relies on an external PKI for establishing trust. This trust model assumes that the PKI interfaces are implemented correctly and that none of the certificate authorities have been compromised. This model provides simplicity similar to that of the pairwise trust model and scalability superior to the brokered trust model. If the remote entity’s key can be retrieved through the PKI interface, a trusted authority has signed its key and it is safe to communicate with it. There must be a mechanism in place preventing two entities from communicating against policy even if they can retrieve each other’s keys. This could be done either through PKI or the individual entities. Adding a new service is as simple as adding its key to the PKI.

Signed SAML assertions have the same security shortcomings as any technology that uses public key cryptography: the private key must not be compromised. The best way to protect against this situation is to keep keys secured and generate new keys on a regular basis. Once an attacker has compromised an entity’s private key, that entity can be impersonated. 32

Whether Web services need to trust one another within a single organization or across multiple organizational boundaries, trust federation frameworks provide support for all of the aforementioned trust models. Section 3.3.2 discusses the various frameworks available for federation of trust.

Trust in distributed computing environments is usually verified using PKI certificates signed by a certificate authority or by passing custom tokens generated by a TTP, as is done in a Kerberos environment. Traditionally, these trust mechanisms have worked well within a single organization. Once information sharing crosses organizational boundaries, entities communicating with one another do not necessarily have the same source of trust. Before the advent of Web services, information sharing across organizational boundaries traditionally was handled by using a proxy that bridges the boundary or by cross-signing certificates.

In a SOA, Web services from multiple organizations should be able trust one another without requiring extensive restructuring of the trust environment. To this end, trust federation frameworks can be configured to use an organization’s pre-existing authentication mechanisms. Liberty Alliance provides both Web application and Web service federation using SAML to perform the trust brokering. WS-Federation allows different security realms to federate by defining trust brokers, who will validate security tokens used between Web services using WS-Trust.

The following subsections provide additional information on the trust frameworks identified above. It must be noted, however, that these frameworks continue to evolve. Thus, the material provided is meant to offer a current snapshot of the features they offer as of this guide’s date of publication.

The following subsections provide additional details of the Liberty Alliance and WS-Trust frameworks. These standards provide similar features and functionality using different techniques and have been designed with different goals in mind. Determining which framework is best for a particular organization depends greatly on what is deployed and on the organization’s architectural goals.

The Liberty Alliance aims to develop a standards-based identity federation framework suitable for businesses and governments. Liberty Alliance-compliant products can interact with one another within a federated environment, allowing organizations to federate identities without having to agree on the same providers.

The Liberty Alliance has defined the Identity Web Services Framework, which defines how Web services can interact on a user’s behalf through appropriate use of SAML by defining several services, including the following:

Discovery Services. Allow Web services to dynamically look up the identity providers of a particular principal

Interaction Services. Provide a mechanism for getting the principal’s permission to perform various actions

Data Services. Provide the Web service functionality that will be used on behalf of the principal

WS-Federation and WS-Trust were developed by IBM, Microsoft, RSA, Verisign, BEA, and several other vendors to create an identity federation system based on extensions to WS-Security that uses the core Web services protocols: SOAP and WSDL. WS-SecurityPolicy is an extension of the WS-Policy framework that allows a Web service to define a set of requirements detailing how messages should be secured and what tokens are required by the Web service. It is used by WS-Trust to determine what tokens are needed to interact with a particular Web service. As discussed in Section 3.1.2, these are referred to as claims.

WS-Trust is used to exchange trust tokens between Web services. WS-Trust is an extension to WS-Security that provides methods for issuing, renewing, and validating security tokens as well as methods for establishing and brokering trust relationships between Web services. If the requester does not supply appropriate claims, it can use the security policy declared by WS-SecurityPolicy to determine the URI of the provider’s Security Token Service (STS), who can provide the requester with the appropriate claims. Additionally, WS-Trust supports multi-messaging exchanges, allowing providers to use a challenge-response mechanism for authorization. Because WS-Trust builds upon WS-Security, claims can be anything from a digital signature to a X.509 certificate or an XML-based token such as a SAML assertion.

WS-Federation expands on WS-Trust by providing various protocols by which STSs (interchangeably called Identity Providers in WS-Federation), requesters, and providers can interact with one another to allow Web services to trust each other across organizational boundaries. Each organization is a separate trust realm. WS-Federation allows Web services to communicate between multiple trust realms. Additionally, WS-Federation provides two profiles for how requesters interact with providers and STSs: the active requester profile and the passive requester profile. The passive requester profile details how messages should be passed between a requester Web browser, the provider, the Identity Providers (IPs) and STSs of both organizations so that WS-Federation can be used within the context of Web applications, providing users with a single sign-on experience. The active requester profile details how requesters should interact with the provider and the IP/STSs to access a provider in another trust realm.

WSDL describes how to communicate with a Web service by detailing the protocol bindings and message formats the Web service expects. In many cases, knowledge of protocol bindings and message formats is not sufficient for requesters to dynamically bind to the provider. WSDL is limited to describing what needs to be placed in the message itself; it does not specify what type of metadata should be supplied, such as how the message will be authenticated or what portions of the message should be signed. To this end, Microsoft, IBM, BEA and others developed the Web Services Policy (WS-Policy) Framework, which allows providers to express the capabilities, requirements and characteristics of the Web service.

WS-Policy requirements can range from specific on-the-wire requirements, such as requiring WS-Security encryption and signatures, to more abstract requirements, such as QoS or privacy requirements. A WS-Policy policy expression can provide senders with the essential metadata to fully automate the task of dynamic binding. A policy expression contains a set of policy alternatives encompassing sets of assertions.

Policy assertions are defined for a number of WS-* specifications, including WS-SecurityPolicy, WS-ReliableMessaging Policy Assertion (WS-RM Policy) and WS-Addressing WSDL Binding. The WS-Policy Primer³⁴ defines how these specifications can be used within a policy expression. As of mid-2007, there are three primary specifications defining WS-Policy assertions:

WS-SecurityPolicy defines assertions to specify integrity, confidentiality, and information about security tokens.

WS-RM Policy defines assertions that can be used to specify how a Web service uses WS-ReliableMessaging.

WS-Addressing WSDL Binding defines elements that can be used within a WSDL descriptor to specify the use of WS-Addressing.

Figure 3-2 shows a sample WS-Policy expression.³⁵

Figure 3-2. Sample WS-Policy Expression

The root expression of the example in Figure 3-2 is an All tag, which is used to specify that all of the contained expressions must be met by the requester for it to comply with the provider policy. The All tag contains the following expressions:

wsap:UsingAddressing, which specifies that requesters should include WS-Addressing information in the SOAP header.

sp:TransportBinding, which specifies that requesters should use TLS to secure the SOAP message and defines the required parameters.

The sp:TransportBinding element contains an All tag containing two expressions:

sp:TransportToken, which specifies what type of token the sender must provide. In this example, sp:HttpsToken indicates that senders must provide a client certificate through TLS.

sp:AlgorithmSuite specifies what algorithms the sender's TLS library must support. In this example, sp:Basic256Sha256Rsa15, defined by WS-SecurityPolicy, is used to indicate that the Advanced Encryption Standard (AES) algorithm should be used with a key size of 256 bits for symmetric cryptography, the 256-bit Secure Hash Algorithm (SHA) should be used for hashing, and version 1.5 of the RSA encryption algorithm for asymmetric cryptography.

WS-Policy can also be used to describe the parameters necessary when using WS-ReliableMessaging to ensure message delivery. Figure 3-3 shows a policy defining an inactivity timeout of 2 seconds, a base retransmission interval of 5 seconds using the exponential backoff algorithm and an acknowledgement interval of 5 seconds.

Figure 3-3. Sample WS-ReliableMessaging Policy Expression

Receivers have the option of specifying whether senders should use TLS or WS-Security to secure SOAP messages. Some receivers may wish to let senders decide which option to support. In this case, the ExactlyOne expression would be used to indicate the option in a manner similar to Figure 3-4.

Figure 3-4. Sample WS-Policy Expression Using ExactlyOne

The ExactlyOne expression in Figure 3-4 contains two expressions related to securing Web service messages between the requester and provider. Senders must choose exactly one of these options when sending a SOAP message to this service:

sp:TransportBinding, which indicates requesters may use SSL/TLS to secure messages

All, which contains two WS-SecurityPolicy expressions that must be followed when using WS-Security in place of SSL/TLS:

Each policy expression can contain an All expression, an ExactlyOne expression or a policy expression element from a WS-Policy grammar, such as WS-Security, WS-RM, or WS-Addressing. Each of these expressions may contain another Policy expression. This level of flexibility allows providers to completely specify the requirements that must be met by requesters beyond those described in the provider's WSDL description.

Policy expressions are external to the metadata stored in UDDI and WSDL, so providers must rely on a separate mechanism for distributing WS-Policy information: WS-MetadataExchange or WS-PolicyAttachment. The WS-MetadataExchange specification defines an encapsulation format for Web service metadata (such as WS-Policy expressions), a mechanism for metadata-driven message exchange, and relies on the WS-Transfer specification to provide a Web service endpoint from which requesters can retrieve the metadata. The WS-PolicyAttachment specification defines how to reference policies from WSDL definitions, how to associate policies with deployed endpoints, and how to associate policies with UDDI entries.

In 2006, WS-Policy and WS-PolicyAttachment were submitted to W3C for standardization. They are scheduled to be released as W3C Recommendations in 2007. In 2005, WS-SecurityPolicy was submitted to the OASIS Web Services Secure Exchange Technical Committee. Even though these specifications are not official OASIS standards, interoperable commercial and open source implementations are available from organizations that were not involved in developing the specification, such as the Apache Software Foundation and Sun Microsystems.

Given the distributed nature of Web services architectures, managing authorization and access control credentials for users in a SOA environment can be challenging. Section 3.5 describes a number of traditional and emerging models and practices that may be extended to capture, manage, and enforce access control decisions for authorized users.

The following subsections describe the authorization models most relevant to access management in a SOA, namely role-based, attribute-based, policy-based, and risk-adaptive access control. While role-based access control models may be familiar to most software designers and developers, knowledge of the other models can provide a perspective on the direction in which Web services access management is heading.

Role-based access control (RBAC) is an authorization mechanism that associates a set of access privileges with a particular role, often corresponding to a job function. With RBAC, all user access is mediated through roles. RBAC simplifies security management by providing a role hierarchy structure. In addition, RBAC has extensive provisions for constraints on user access based on administrator-defined relationships. This feature makes it possible to implement complex controls such as separation of duty. Constraints can include either static or dynamic attributes. Most commercially available RBAC systems conform to some of the RBAC standards, which are summarized on the NIST RBAC Web site.³⁶ Additionally, OASIS provides the Core and hierarchical role based access control profile of XACML, allowing organizations to support RBAC using the flexible and platform-independent XACML specification.³⁷

In most cases, COTS Web servers or Web service platforms will support designation and assignment of privileges to roles as part of their standard definition of user accounts and access control privileges. In worst cases, the administrator will have to create the necessary user groups, enroll the appropriate users, and assign them role-appropriate privileges.

RBAC on a Web service platform should be implemented at a minimum for the administrator, developers, and any other privileged accounts that will be required for the Web service to operate. The Web service platform must be configured to enforce separation of roles (i.e., not allowing a user assigned to one role to perform functions exclusively assigned to another role). The privileges associated with each role should be assigned in a way that implements least privilege—each role should be assigned only the minimum privileges needed to perform the functions required by the role.

Most vendors implement some form of RBAC in their core Web services products. Another alternative is to implement or deploy RBAC at the Web services level, which is supported by a number of XML gateways and Web service vendors. However, the RBAC policies supported are less granular because a COTS product may need to be generic so it can support many different types of organizational policies.

ABAC provides a mechanism for representing a subject’s (either a user or application) access profile through a combination of the following attribute types:

ABAC policy rules are generated as Boolean functions of S, R, and E attributes and dictate whether a subject S can access a resource R in a particular environment E - as loosely indicated in Figure 3-5:³⁸

Figure 3-5. ABAC Policy Function

ABAC clearly provides an advantage over traditional RBAC when extended into SOA environments, which can be extremely dynamic in nature. ABAC policy rules can be custom-defined with consideration for semantic context and are significantly more flexible than RBAC for fine-grained alterations or adjustments to a subject’s access profile. ABAC also integrates seamlessly with XACML, which relies on policy-defined attributes to make access control decisions.

One additional benefit to Web service implementations of ABAC lies in the nature of the loose definition of subjects. Because ABAC provides the flexibility to associate policy rules to any actor, it can be extended to Web service software agents as well. Figure 3-6 illustrates how an ABAC attribute authority (AA) can be integrated with a SAML framework. In this diagram, the AA generates attribute assertions, which contain all the attributes necessary for an access control decision based on an ABAC policy written in XACML. The PDP uses the attribute assertions, the authentication assertion, and the XACML policy to generate an authorization decision assertion. XACML is discussed in detail in Section 3.5.4.

Figure 3-6. Use of SAML and XACML in Implementing ABAC

In Figure 3-6, the requester’s authentication assertion is provided by the identity provider before accessing the resource. The following steps describe how SAML and XACML use the requester’s attributes to determine whether access should be granted:

Policy-based access control (PBAC) is a logical and somewhat bounded extension of ABAC that is useful for enforcing strict environment-level access control policies. PBAC introduces the notion of a policy authority, which serves as the access decision point for the environment in question. PBAC leverages the granular policy rule functions inherent to ABAC; it focuses more on automatically enforcing mandatory access controls (MAC), which are traditionally much more bounded than discretionary controls.

Risk adaptive access control (RAdAC) is another variation on traditional access control methods. As opposed to RBAC, ABAC, and PBAC, however, RAdAC makes access control decisions on the basis of a relative risk profile of the subject and not necessarily strictly on the basis of a predefined policy rule. Figure 3-7 illustrates the logical process governing RAdAC, which uses a combination of a measured level of risk the subject poses and an assessment of operational need as the primary attributes by which the subject’s access rights are determined.

Figure 3-7. RAdAC Decision Tree

As a policy-driven mechanism, RAdAC is ostensibly an abstraction of PBAC. Unlike PBAC, however, a RAdAC framework requires associations with sources that are able to provide real-time, situation aware information upon which risk can be assessed with each authentication request.

Trust and privilege are not synonymous. This said, trusted objects are often used to perform privileged functions. Least privilege can and should be applied regardless of what access control methodology is in use. In a Web services environment, each Web service should be designed to not request or expect to obtain privileges that exceed the minimum privileges it needs to perform its current operation.

Because of the functions they perform, trusted objects often require higher privileges than untrusted objects. Regardless of whether an object is trusted or untrusted, a privilege should be granted to it only at the moment the object needs that privilege, and the object should relinquish the privilege as soon as it completes the function/access for which the privilege was needed. Objects should not be allowed to retain a privilege that they are not actively using. Privileges should never be granted in anticipation of their being needed to perform some function/access in the future.

The application’s design should ensure that only a minimal number of application objects need to be trusted or are ever granted privileges that exceed those of the end users that are associated with those objects. Whenever possible, implement objects without privileges, and if necessary, divide the complex functions they must perform into multiple simple functions, with a separate minimal required privilege for each function.

The application should also support minimization of permissions granted to a user, with each user granted only those minimal privileges needed to execute the application and access the data/resources for which the user is authorized. In most cases, user privileges will be determined by the user’s role. As with other application objects, user privileges should be assigned at the moment they are needed, and revoked as soon as they are no longer being used.

Web services should be designed so that only a few components perform trusted operations. By restricting trusted functions to a small number of components, the overall architecture is simplified and the potential attack scenarios are minimized. Nevertheless, trusted functions should not be limited solely to a single component, which introduces a single point of failure. If the single trusted component fails, none of the dependent components will be able to function adequately, leading to a loss of availability. Trusted Web services should be deployed to be as available as possible.

There are three important concepts to consider when developing the access control policy for Web services. These concepts apply equally within the OS itself and within the SOA as a whole.

Separation of Duties. Developers should write Web services to require only appropriate system roles or attributes to operate correctly.

Separation of Roles and Separation of Privileges. The roles or attributes required for Web services should directly correspond to the set of functions to be performed.

Separation of Domains (Compartmentalization). Access control policy may benefit from separating Web services into various compartments. For example, separating roles associated with rate service A from those associated with rate service B will allow an administrator to modify each service’s permissions separately. The difficulty of compartmentalization depends on the access control mechanism used: this could be implemented in ABAC using resource attributes or through additional roles in RBAC.

Note that most general purpose operating systems’ access controls cannot isolate intentionally cooperating programs. If the cooperation of malicious programs is a concern, the application should be implemented on a system which implements mandatory access controls and limits covert channels.

SAML defines an XML vocabulary for sharing security assertions that specify whether and how an entity was authenticated, information about an entity's attributes or whether an entity is authorized to perform a particular action. These assertions enable identity federation and distributed authorization within a SOA.

The SAML specification defines a framework for creating and exchanging generic assertions with given validity periods, signatures, encrypted elements and unique identifiers (among other attributes). Assertions are associated with a given subject (a named entity). When using SAML, there are two parties: the relying party and the asserting party. The asserting party asserts information about a particular subject, such as whether or not a user has been authenticated or has a particular attribute. The relying party uses the information supplied by the asserting party to make decisions, including, but not limited to, whether or not to trust the asserting party's assertion. By trusting the asserting party’s information, the relying party can provide services without requiring the principal to authenticate again.

SAML assertions contain a number of required elements (except where otherwise noted):

ID. Uniquely identifies this assertion

IssueInstant. Timestamp indicating when the SAML assertion was created

Issuer. Information about the entity that created the assertion

Signature. Digital signature of the SAML assertion (optional)

Subject. Information about the entity to which this assertion applies (optional)

Conditions. Information used to determine the validity of the assertion, such as a validity period (optional)

Advice. Information that may be useful in processing the assertion (optional)

Statements. SAML statements can provide information about subject authentication, authorization decision or attributes. Additional types of statements can be defined by an extension. (optional)

Figure 3-8 shows a SAML assertion containing a single authentication statement. This assertion indicates that John Doe was authenticated on January 15, 2007 at 14:15:07 UTC via X.509 certificate and that this assertion is valid for one hour from the initial time of authentication.

Figure 3-8. SAML Assertion

In addition to having digital signatures, SAML assertions may be encrypted using the EncryptedAssertion element, preventing third party entities from viewing the assertion.

SAML defines three types of statements—authentication, attribute, and authorization—allowing SAML assertions to provide a wealth of information about individual subjects.

SAML authentication statements indicate that a subject was authenticated and provide specific details, such as what authentication method was used, when the authentication occurred, and who the authenticating entity was. Different techniques for establishing identity are supported, ranging from use of a password to use of hardware tokens and personal physical attributes (biometrics). SAML allows assertions to specify any type of authentication mechanism used and provides a vocabulary for a number of commonly used mechanisms. Figure 3-8 shows a sample authentication statement.

A SAML authorization decision statement may be used to assert that a request by a subject to access a specified resource has resulted in the specified decision and may optionally include evidence to support the decision.

SAML attribute statements provide information about a particular subject that may be useful or necessary for determining whether or not access should be granted. In an RBAC environment, a SAML attribute statement can provide information about the subject's roles; similarly, in an ABAC environment, a SAML attribute statement can provide the attributes required by the policy.

The SAML specification defines the SAML protocol, an XML-based request and response protocol for processing SAML assertions.³⁹ The SAML binding specification describes how to embed SAML requests and responses within HTTP and SOAP, allowing SAML to support both traditional Web applications and Web services.

As shown in Figure 3-9 below, SAML requests contain the following required information (unless otherwise specified):

ID: uniquely identifies the SAML request

IssueInstant: a timestamp indicating when the request was made

Destination: a URI representing the receiver of the SAML request (optional)

Consent: indicates whether or not the principal's consent was obtained for the request (optional)

Issuer: identifies the sender (optional)

Signature: a digital signature of the request (optional)

Extensions: optional extensions, such as the XACMLPolicyQuery element defined by the XACML 2.0 SAML Profile (optional)

Figure 3-9. SAML Protocol Request

As shown in Figure 3-10 below, SAML responses contain similar information (required unless otherwise specified):

ID

InResponseTo: the ID of the corresponding request (optional)

IssueInstant

Destination (optional)

Consent (optional)

Issuer (optional)

Signature (optional)

Extensions (optional)

Status: a code representing the status of the response (optional).

Figure 3-10. SAML Response

SAML requests and responses are extended by each of the SAML protocols, providing support for a variety of SAML use cases. The SAML specification defines six protocols, allowing extensions to provide support for future protocols.

The assertion query and request protocol allows services to request specific assertions from a SAML authority. Services can request an assertion based on its ID, or query for authentication, attribute or authorization decision assertions.

The authentication request protocol allows services to request that an entity be authenticated by the identity provider; the subject may be authenticated before, during, or after the identity provider receives the authentication request. The authentication request protocol can play an important role in authenticating users in a seamless fashion when traversing from a publicly available service to a protected service. Similarly, the authentication request protocol can support re-authenticating subjects or requiring stronger authentication when accessing sensitive services.

The artifact resolution protocol allows a SAML provider to retrieve a SAML message based on its artifact, which is a reference to the message. The SAML-aware service passes the artifact to the provider instead of the SAML message itself. Artifacts are intended to be used when the transport mechanism has size constraints or cannot provide a secure channel through which to send a SAML message. For example, a SAML artifact can be passed as an HTTP GET parameter, allowing a traditional Web browser to pass a SAML assertion from the identity provider to a Web application without requiring the Web browser to be SAML-compliant.

The name identifier management protocol provides a mechanism through which SAML identity providers and service providers can notify one another that a principal's identifier has a new or modified value or format. Identity providers supply a ManageNameIDRequest element containing a NameID or EncryptedNameID element and NewID, NewEncryptedID, or Terminate element. Privacy concerns may be met by submitting the identifiers in encrypted form. Through the Terminate element, an identity provider can inform service providers that it will no longer supply assertions for the specified principal, or a service provider can inform the identity provider that it will no longer accept assertions for the specified principal.

The single logout protocol allows a principal to simultaneously log out of multiple sessions from a single service provider. When a principal has authenticated to an identity provider, the identity provider may initiate a session so that the principal does not need to re-authenticate (the identity provider becomes a session authority). When the principal accesses service providers, they may wish to initiate sessions to alleviate the need to communicate with the identity provider for each of the principal's requests (the service provider becomes a session participant). Should the principal wish to terminate all sessions associated with the initial authentication, a LogoutRequest may be sent to any of the session participants. If a session participant received the LogoutRequest, it will forward the LogoutRequest to the session authority. The session authority will send a LogoutRequest to all session participants except for the participant that initiated the LogoutRequest. The single logout protocol ensures that the principal does not need to be aware of all sessions associated with the original authentication.

The name identifier mapping protocol allows a provider to request a principal's name identifier from an identity provider in a specific format. A service provider must send a NameIDMappingRequest to the identity provider with a BaseID, NameID or EncryptedID element identifying the principal and a NameIDPolicy element indicating the format of the identifier to be returned. Use of an EncryptedID element can ensure that the principal's privacy is adequately maintained during the exchange. The identity provider will return a NameID or EncryptedID that satisfies the request parameters.

The SAML specification provides a number of profiles⁴⁰ that specify how SAML messages, assertions and protocols are to be used in various contexts. Because SAML is a versatile specification, there are five categories of profiles. Some categories only define a single profile, leaving room for future SAML specifications to expand. The five profile categories are:

Single sign-on (SSO). These profiles define the protocols necessary to support SSO across multiple Web applications. There are profiles defining how to support SAML SSO when the client uses a

Web browser or a SAML-aware client or proxy, a profile for discovery identity providers, a profile for single logout, and a profile for managing identifiers among multiple service providers.

Artifact resolution. This profile defines how SAML-aware providers should retrieve the SAML assertion associated with a SAML artifact provided by a requester.

Assertion query/request. This profile describes how to use the SAML assertion query/request protocol over a synchronous protocol, such as SOAP.

Name identifier mapping. This profile describes how to use the SAML name identifier mapping protocol.

Attribute. These profiles define how to represent attributes from common attribute stores in SAML assertions.

In Web services, attributes are usually disseminated using either SAML attribute assertions or X.509 certificates containing the required attributes. While X.509 certificates only provide a limited set of attributes, SAML attributes can encompass any type of attribute. In most enterprise systems, user attributes are stored in various Lightweight Directory Access Protocol (LDAP) or X.500 directories, Relational Data Base Management Systems (RDBMS), or Active Directories (AD). In the SAML architecture, these are referred to as attribute stores. By abstracting the various forms of attribute stores into a single entity, the SAML request/response protocol can be used to query any attribute store, regardless of its underlying structure.

Through the SAML attribute profiles, interoperability between the attribute store’s SAML interface and the Web service accessing it is guaranteed. SAML V2.0 provides attribute profiles for X.500/LDAP attributes, Universally Unique Identifiers (UUID), DCE PAC attributes, and XACML attributes. The X.500/LDAP, UUID, and DCE PAC attribute profiles detail how to convert between SAML attributes and the structures of the individual attribute stores. While XACML is not an attribute store, the XACML attributes profile details how SAML assertions can be used as input to XACML authorization decisions. SAML can be extended to support any other form of attribute store, allowing attributes to be accessed in a Web services environment.

While SAML provides a mechanism for accessing attributes, it does not provide a mechanism for updating attributes in a SOA. As of this writing, there is no Web services standard for modifying the contents of data stores used by a SOA. For Web services to alter the contents of the various attribute stores, custom Web services would have to be developed using appropriate WS-Security and authorization techniques.

The Security and Privacy Considerations for the OASIS Security Assertion Markup Language⁴¹ document⁴² outlines the threats faced when using SAML and provides guidance in securing a SAML-based architecture. In particular, it is important to recognize that once a SAML assertion has been issued, it is not possible to control its dissemination. An entity that receives a SAML assertion may pass it on to other, potentially malicious entities as part of the system. It is important to ensure that all SAML assertions and entities that will receive them follow appropriate organizational policies. Because of this, it is possible that a malicious entity may attempt to use SAML assertions in replay attacks (in particular, authentication assertions and authorization decision assertions are likely to be replayed). There are a number of techniques that can mitigate this threat, including:

Encrypting the assertion will prevent a third party from viewing it, although a malicious entity may attempt to resend the encrypted assertion.

Signing the entire message rather than the assertion itself, using WS-Security in a SOAP response or SSL/TLS in a HTTP response. This way, an attacker must resend the whole message to be successful.

Enforcing validity periods and ensuring that the IssueInstant of the assertion is reasonable. This will minimize the amount of time during which an attacker may successfully execute a replay attack.

If a SAML authority is publicly accessible, an attacker may send SAML queries to gain information about the subjects within the system. Similarly, an attacker may construct a malicious SAML authority. In each case, it is especially important that entities using SAML authenticate one another before requesting or providing information about subjects within the SOA.

Within Web services extensions, a vocabulary is required for expressing the rules needed to make authorization decisions. One such vocabulary is XACML. XACML is a language- and platform-neutral method for representing and enforcing security policies. Using XML as a basis for a security policy language is the natural choice because its syntax can easily be extended to conform to the requirements of individual applications. XACML defines both a policy language and a request/response language for access control decisions. The policy language is used to define the access control requirements of a particular system or organization. The request/response language provides a mechanism for asking whether or not a particular action is allowed. XACML also defines a method for mapping the request to the policy and determining whether or not the policy allows the requested action.

XACML is used in conjunction with SAML to provide a means for standardizing access control decisions for resources over a network. XACML uses a context that can easily be mapped on SAML requests to determine if access should be granted to a resource based on XACML policies. Once the policy is evaluated and returns a true or false value to indicate whether or not access is granted, a SAML authorization decision assertion is returned, which is then processed accordingly.

The following subsections describe additional details on the XACML specification, including major inherent features and a discussion of how the transparent components of XACML operate in the background. Also provided are summaries on how XACML is implemented in a SOA and examples of practical extensions/implementations of XACML within the community.

XACML defines a language for creating policies. The basic elements for policies are Policy and PolicySet. A PolicySet can contain Policies and references to external policies. A Policy defines a single access control policy that is expressed through one or more Rules. XACML defines several combining algorithms for determining a single decision from the results of multiple rules. Figure 3-11 shows an XACML policy that uses the permit-overrides combining policy in which any result of “permit” will grant access. This policy shows that members with a group attribute of “developers” can perform the read action on http://server.example.com/code/docs/guide.html.

Figure 3-11. An XACML Policy

The XACML specification uses the term policy enforcement point (PEP) to refer to the entity that performs the access control, such as a file system or Web server. The PEP sends XACML requests to the PDP and receives XACML responses that it uses to grant or deny access. The PDP is the entity that receives access requests from the PEP. It looks at the request and the applicable policy and sends a response as to whether or not access should be granted.

Figure 3-12 shows an XACML request in which the user, jsmith@users.example.com, is attempting to perform a read action on http://server.example.com/docs/guide.html. This request provides the user’s group attribute, which is required by the policy to make the access decision. From the request, jsmith@users.example.com’s group attribute is “developers.” This request is sent by the PEP to the PDP.

Figure 3-12. An XACML Request.

Once the PDP receives the request, it processes the request against the policy provided in Figure 3-11. Because jsmith@users.example.com’s group attribute is “developers”, the resulting decision is “permit.” This decision is sent to the PEP in the form of an XACML response as shown in Figure 3-13. The PEP will then permit jsmith@users.example.com to read http://server.example.com/code/docs/guide.html.

Figure 3-13. An XACML Response

Access control policies are comprised of Targets and Rules. A Target defines a set of conditions for the Subject, Resource, and Action that must be met for a PolicySet, Policy, or Rule to apply to a request. The Target is used by the PDP to determine whether or not the request applies to this particular rule. Once an applicable policy is found, the Rules are activated. Most Rules consist of an Effect and a Condition. The Effect determines what the results of the Condition mean, while the Condition can test that any attribute meets a certain requirement.

Attributes are used in XACML to aid in creating access control policies. In essence, attributes refer to individual properties of the Subject, Resource, Action, or Environment that are applicable to the access request, such as the Subject’s user name or the Environment’s current time. A Policy uses the AttributeDesignator and the AttributeSelector to retrieve attributes from a request. The AttributeDesignator specifies an attribute with a given name and type that the PDP will retrieve from the request or some external source. AttributeSelectors provide an XPath query for resolving the values in the request or elsewhere. The attributes received are used in Rules to determine whether or not to grant access.

XACML does not have the inherent ability to control access to anything. It is used to provide an access control policy and to determine whether or not a requested action is allowed. The policy and requested action can be anything from read-access of a particular element in an XML file to a request for entry through a physical door. When using XACML in a Web service or Web application, it is important to understand that the application itself must be the PEP. All requests for information from the client or requester service must be translated into an access request. In many implementations, XACML is used solely for authentication, in which case only the authentication request needs to be translated while all subsequent requests would be allowed. As mentioned earlier, the PEP needs to send XACML requests to the PDP. The PDP will take the XACML request and determine the appropriate XACML response to send to the PEP, which will then grant or deny the request.

Because there is no mechanism for transmitting XACML over a network in the XACML specification, SAML is traditionally used to transmit requests, responses, and attributes over a network. SAML was designed for the secure exchange of authentication and authorization information, but not for performing the actual decisions. This makes it a perfect match for transmitting XACML information over a network. The PEP converts the XACML request into a SAML query and sends it to the PDP. The PDP converts the SAML query into an XACML request and processes the request against the XACML policy. The XACML response is converted into a SAML response and sent back to the PEP, which converts it back into an XACML response. SAML does not provide message confidentiality—only message integrity. If any of the data being transmitted is sensitive, it must be transmitted using SSL/TLS or WS-Security. If the SAML protocol is being used without SSL/TLS, all SAML messages must be signed appropriately.

The XACML v2.0 specification only supports a configuration where the PDP and PEP are on the same system. There is no standard specified for transmitting XACML policies, requests, or responses over a network. SAML is designed for the secure transmission of security attributes, which are used by XACML to determine whether or not to grant access. To this end, SAML v2.0 includes an XACML binding.

Because XACML can be used over a variety of languages and platforms, tools for generating XACML policies can be used for any application and platform that supports XACML, unlike current policy generators that only work with a specific application.

While not developed specifically for access control, XML schemas can be effective for controlling access to Web services. XML parsing libraries often support validating XML documents against a defined XML Schema. Because XML Schemas can rigidly define the types of data and format of XML elements, they can be used to prevent the Web service from processing invalid requests. For example, the SOAP XML Schema could be modified by a Web service developer to only allow portTypes that match a particular regular expression. All other requests would not pass through the XML validator and would not reach the Web service. In addition, the XML parser could be configured to use a different XML Schema based on the identity of the remote Web service, which would not require the developer to implement the necessary authorization functionality in the Web service itself. In fact, use of XML Schema-based access control could prove to be more powerful than programmatic access control since many malicious SOAP requests would not reach the application code. One of the drawbacks of using XML Schema validation for access control is that it could put a heavy load on the system, because Schema validation is processor-intensive; this could lead to a degradation of service.

If the Web service handles personally identifiable information (PII), proprietary, or other sensitive data, it may need to label or otherwise mark output from the application. For labeling of Web pages, one approach is to use metatags to store the label information directly in the HTML source of the page, to be displayed as part of the page in the user’s browser. If the Web page is printed from the browser, this label will be included in the printed output.

Some government agencies have defined XML-based markup syntax and schema for implementing security labels in data. The Intelligence Community (IC) Metadata Standards Working Group (MSWG) develops standards for affixing security labels to online XML and HTML content and downloadable electronic documents posted on the IC’s Intelink World Wide Web-like intranet. While these standards are developed specifically for the IC, they can serve as a basis for any organization’s metadata standards. In addition, any organization that interacts with the IC may improve communications efficiency by embracing these standards.

The IC security metadata standards are intended to be consistent with the key XML security standards (XML-Signature, XML-Encryption and XKMS). The relevant IC standards are:

IC Metadata Standard for Publication (IC MSP)

IC Metadata Standard for Information Security Markings (IC ISM)

IC Standard for Core Metadata (IC Core).

Within DoD, a similar effort has been put forth called the DoD Discovery Metadata Standard (DDMS). DDMS does not directly support embedding metadata tags within XML documents. Instead, it focuses on creating metadata registries that can be accessed in conjunction with DoD resources. As with the IC standards, use of DDMS may improve efficiency in communications for organizations that interact closely with DoD.

The DoD and the IC are working on harmonization of security labels based on the labeling specifications defined by the IC’s Controlled Access Program Coordination Office (CAPCO) and those based on DoD Directive 5200.1, DoD Information Security Program (13 December 1996).⁴³

In the private sector, a number of organizations are developing metadata specifications to address regulations such as the Health Insurance Portability and Accountability Act (HIPAA) of 1996. The Food and Drug Administration (FDA) approved the Structured Product Labeling (SPL) specification from Health Level Seven (HL7) as a mechanism for exchanging medication information. SPL Release 244 provides confidentiality codes that can be used to specify whether a particular entity can view the information in the document.

The objective of these standards is to describe XML metadata tags and their possible values. These tags and values can be embedded in XML content to indicate the classification or sensitivity level associated with the tagged data. In addition, the standards describe one or more DTDs or XML Schemas specifying the rules for parsing the metadata security tags.

Although transport layer security mechanisms are provided through using secure transport protocols such as SSL/TLS, message layer security of XML is still needed for the following:

End-to-End Security. Secure transport protocols can assure the security of messages only during transmission. Because messages are received and processed by intermediaries, secure end-to-end communication is not possible if these intermediaries are not completely trusted.

Transport Independence. Even if all the communication links are secure and the intermediaries can be trusted, security information such as the authenticity of the originator of the message needs to be translated to the next secure transport protocol along the message path. This could be tedious and complex, which may lead to security breaches. It is important to deal with the security concerns at the message layer independently of the transport layers.

Security of Stored Messages. Once a transmission is received and decrypted, transport layer security does not protect data from illicit accesses and alterations. In situations where messages are stored and then forwarded, message layer security is necessary.

The following subsections describe technologies that may be leveraged to improve the confidentiality and integrity of Web services. This includes both session/transport level security (i.e., SSL/TLS) as well as message-level security, such as that provided through WS-Security (as described below). Integrity can be enforced to an extent through the use of XML gateways (i.e., XML firewalls), and further explanation of this notion is provided in Section 3.6.4.

Because Web services rely on HTTP as the transport layer, they can be easily configured to communicate over HTTP Secure (HTTPS). The HTTPS protocol is defined as HTTP over SSL/TLS. SSL/TLS provide socket-layer security, encrypting all communication over a particular TCP connection— immediately granting an insecure application-layer protocol security without altering it. Through SSL/TLS, HTTPS supports authentication, confidentiality, and integrity of data sent between the endpoints. Use of HTTPS provides the following:

Each service only needs to have knowledge of those services it directly communicates with, which reduces the certificate distribution problem.

Each Web service uses the framework’s authentication and authorization mechanism rather than implementation-specific code.

The XML security standards define a framework and processing rules that can be shared across applications using common tools, avoiding the need for extensive customization of applications to add security. The XML security standards reuse the concepts, algorithms and core technologies of legacy security systems while introducing changes necessary to support extensible integration with XML. This allows interoperability with a wide range of existing infrastructures and across deployments.

The XML security standards define XML vocabularies and processing rules using established cryptographic and security technologies, to provide flexible, extensible and practical ways of satisfying security requirements. The core XML security standards include the following:

XML Signature. For integrity and signatures, XML Signature defines digital signatures and related cryptographic integrity and authentication measures for XML.

XML Encryption. For confidentiality, XML Encryption supports encryption using a variety of both symmetric and asymmetric cryptographic algorithms.

XML Key Management Specification (XKMS). For key management, XKMS addresses PKI and key management network services in XML.

Many other confidentiality and integrity technologies, such as SSL/TLS or virtual private networks (VPN), only provide confidentiality while the information is in transit, not while it is stored at a server. XML Encryption and XML Signature use the same cryptographic algorithms as other cryptographic technologies and may be subject to similar attacks. All applications depending on XML Encryption and XML Signature should follow the guidelines set forth in NIST SP 800-21-145, SP 800-3246, SP 800-5747, FIPS 140-248 and FIPS 186-249.

XKMS defines protocols for Public Key management services. Public Key management includes the creation of public and private key pairs, the binding of key pairs with identity and other attributes, and the representation of key pairs in different formats. Public key technology is essential to XML Signature, XML Encryption, and other security applications. When signing, the private key is used to sign and the public key is used to verify signatures. When encrypting, the public key is used to encrypt and the private key is used to decrypt. In both cases, the private key must be maintained under control of the owner and the public key may be shared with others. XKMS is designed to help manage the sharing of the public key to enable signature verification and encryption. XKMS enables users to delegate key management functions to a trust service accessed via SOAP and XML. XKMS enables key management to be provided as a service to the application, without having to use a PKI toolkit to implement the service.

When using XML Security standards in Web services, both the requester and provider must support the particular algorithms chosen and must decrypt or verify the SOAP messages before acting upon them. Also, because the SOAP specification does not provide support for encrypting portions of SOAP messages, both SOAP endpoints must understand the protocol and tags used to represent encrypted or signed SOAP elements. To prevent proprietary and incompatible Web service security mechanisms, the WS-Security standard was developed by Microsoft, IBM, and Verisign to define a unified mechanism for securing SOAP messages.

As mentioned earlier, the WS-Security standard was designed to use the XML Encryption and XML Signature specifications for message-layer confidentiality and integrity. By signing and encrypting at the message level, senders control whether intermediaries can modify or view the content in transit. Additionally, the entire message can be stored intact, maintaining integrity or confidentiality while at rest. Because message integrity is provided by digital signatures, non-repudiation can be achieved by logging individual messages for later retrieval (Section 3.7.2 describes non-repudiation in more detail). To fully support WS-Security, a Web service needs to be able to access public keys for all nodes with which it will interact, not simply those nodes it communicates with directly. This allows WS-Security to prevent man-in-the-middle attacks.

One of the main drawbacks associated with WS-Security is its use of asymmetric cryptographic algorithms for encryption, which are computationally intensive. To remedy this situation, the WS-SecureConversation specification was developed, allowing Web services to create a symmetric session key (similar to how SSL/TLS functions) to allow faster symmetric cryptographic algorithms to be used for message-level security. WS-SecureConversation is well-suited for Web services that receive or send large volumes of messages to a small number of services.

SOAP travels over HTTP, which is traditionally left open for Web traffic at perimeter firewalls. Additionally, with the advent of Liberty and SAML V2.0’s Reverse SOAP (PAOS) specification, SOAP messages can pass through firewalls that limit incoming HTTP traffic but allow outgoing HTTP traffic. Some firewalls have begun to support blocking or allowing SOAP requests based on the source or destination of the request, but more robust and intelligent firewalls are needed to defend networks against malicious SOAP attacks.

To this end, XML gateways were developed to offer the functionality of application-level firewalls specifically for Web services. Application-aware firewalls are nothing new; they have been around in the form of HTTP proxies for HTTP-based traffic and allow organizations to limit what an application-layer protocol can and cannot do.

An XML gateway acts as the Web service and forwards all communication to the internal Web service, acting as an intermediary between untrusted services and the internal Web service. XML gateways can provide sophisticated authentication and authorization services, potentially improving the security of the Web service by having all SOAP messages pass through a hardened gateway before reaching any of the custom-developed code. XML gateways can restrict access based on source, destination, or WS-Security authentication tokens.

XML gateways also support schema validation and some offer support for SOAP intrusion prevention against the following attacks that target vulnerabilities native to XML and XML based services:

WSDL scanning. Attempts to retrieve the WSDL of Web services to gain information that may be useful for an attack

Parameter tampering. Modification of the parameters a Web service expects to receive in an attempt to bypass input validation and gain unauthorized access to some functionality

Replay attacks. Attempts to resend SOAP requests to repeat sensitive transactions

Recursive/oversized payload attacks. Attempts to perform a denial of service against the Web service by sending messages designed to overload the XML parser

External reference attacks. Attempts to bypass protections by including external references that will be downloaded after the XML has been validated but before its processed by the application

Buffer overflows. Providing specially crafted parameters that will overload the input buffers of the application and will crash the Web service—or potentially allow arbitrary code to be executed.

Additionally, Web services behind an XML gateway may not need to implement the security functionality provided by the firewall, allowing developers to focus only on what the firewall does not support. Because SSL/TLS can be used between the firewall and the Web service, all communication between the Web service and the XML gateway can be trusted. If Web services behind the firewall do not implement security mechanisms to support confidentiality, integrity, and authentication, attackers that bypass the XML gateway may be able to subvert internal Web services. As such, it is always beneficial to implement defense-in-depth using XML gateways at the perimeter along with WS-Security or HTTPS for all internal Web services.

Finally, XML gateways support in-depth logging facilities for audit purposes. In conjunction with individual audit logs at each Web service, this allows administrators to keep track of what anomalies the XML gateway is experiencing to potentially fine-tune the XML gateway or notice when an attack has been successful and compromised an internal Web service. Nevertheless, the effectiveness of an XML gateway is dependent on the richness of the feature set and the granularity of policy control. Like any Web service, XML gateways are susceptible to threats from external attackers, so it is important to apply updates and define a policy for handling any intrusions related to the XML gateway.

Because of the SOA property allowing Web services to dynamically bind to one another, it is difficult to implement accountability in a service chain. Auditing is essential in many transactions to be able to ensure, after the fact, that the transaction took place as expected. For example, financial transactions often require extensive auditing. The lack of auditing standards for Web services serves as the primary hindrance to effectively implementing accountability across a SOA.

In a SOA, auditing is accomplished by using a secure, distributed logging facility and WS-Security digital signatures. Through the use of a secure logging facility, all important WS-Security signed elements can be stored for audit purposes to determine which Web service performed what action. One common mechanism for implementing the logging facility is to develop Web service intermediaries that transparently log information about captured SOAP messages. Web services developed from scratch can be implemented to support an organization’s distributed logging facility, but many COTS and government off-the-shelf (GOTS) Web services use their own non-standard logging mechanism. Standards efforts are on the horizon to enable interoperability between logging mechanisms, but until they are in place, organizations must support the wide variety of logging mechanisms in use.

Regardless of what logging mechanisms are in use within an organization, there is no way in a SOA to require all participants in a service chain to use WS-Security or logging. For example, one member of the service chain may not perform logging but may advertise that it does; while another member of the service chain does not support WS-Security but the service that accesses it performs signatures itself. It is important that the Web services a requester communicates with be trusted—and that trust should imply that each subsequent service in the chain will be held to the same standard of trust. When going through audit logs it will be apparent which member of a service chain did not follow the requirements of the SOA, as the required logs or signed elements will not be available for examination.

Enforcing accountability in a SOA (or other) environment requires the use of diligent auditing mechanisms, such that forensic data can be captured, compiled, and accurately attributed to users. The following subsections explain how auditing can be performed in SOAs. Section 3.7.2 explains the relevance of non-repudiation in a Web services environment and the means by which it can be enforced.

Most COTS Web servers include an audit or security event logging service that provides the application with the mechanism it needs to log security events to multiple destination logs. Configurable property-driven parameters allow the administrator to modify the semantics of the application’s log data capture without needing to rewrite the application code. For example, Java’s standard logging API provides an extensible event logging service for many Java applications. Logging and audit entries captured may be routed to the local operating system audit trail, or to audit middleware, using pluggable logging modules.

As noted, the audit/security event log data must be stored securely to prevent unauthorized tampering or disclosure of the log data. This secure storage may be implemented by channeling the log data via a secure connection to an external audit system, such as a central audit collection server, audit middleware, or the operating system audit trail. The audit/security event logs should be secured, either by transmitting the log data via an encrypted API, socket, or network connection, or by encrypting the log data before transferring them via an unencrypted or encrypted channel. In the case of a COTS audit server or audit middleware, the secure interface will ideally be provided as a standard feature of that product. If it is not, the application could provide it using a secure protocol or tunnel common to both it and the external audit system. Many organizations provide a logging core service within their SOA that other Web services can dynamically bind to securely submit logging data for storage in a central location. In addition to storing audit information on a remote system, it may be beneficial for Web services to store audit information locally in the event the central logging service fails or is temporarily inaccessible. NIST SP 800-9250 provides guidance on managing security logs throughout an organization. While this guidance is not specific to SOA, many of the concepts introduced in the guide can be applied to Web services.

WS-Security provides non-repudiation services through its use of the XML Signature standard. Digital signatures can provide the necessary level of assurance required for non-repudiation. Through asymmetric encryption, each Web service has a unique key that can be used to sign SOAP elements. This signature can be verified by any subsequent Web service to verify which Web service performed the signature—and verify whether or not the signed element has changed, as a digital signature is only valid if the signed data remains unchanged.

WS-Security can provide non-repudiation of both the SOAP message itself and its contents. WS-Security supports signing the SOAP header, to ensure that the recipient and sender of the SOAP message have not changed since the message was sent. The SOAP message can be logged so that an audit can reveal that the SOAP message was valid. Additionally, sensitive information can be signed by another Web service for inclusion in the SOAP message. This allows a Web service to include signed data in different SOAP messages while maintaining that the original Web service signed the data—allowing the message sender to sign the SOAP header for a message that was originally sent by a different Web service. This can be particularly useful in Web service choreographies and orchestrations as the data may pass between a number of Web services before reaching its intended destination.

There is a close relationship between availability, QoS, and reliability. Availability is intended to ensure that QoS and reliability are maintained even when the Web service is subjected to intentional attempts to compromise its operation.

Where QoS is concerned with ensuring the Web service consistently operates at its expected level of performance, and reliability deals with ensuring the Web service continues to operate correctly and predictably in the presence of unintentional faults, availability ensures that:

The Web service will continue to operate correctly and predictably in the presence of the types of intentionally-induced faults associated with DoS attacks

If the Web service cannot avoid failing, it will not fail into an insecure state (i.e., its failure will not leave the service itself, its data, or its environment vulnerable to being compromised, subverted, or exploited to compromise something else) unless organizational policy requires the service to continue operating.

To achieve availability, a Web service must not only be designed and implemented to achieve QoS and reliability, but also to:

Recognize and react to the attack patterns associated with DoS.

When resistance is no longer possible, constrain and isolate the results of the DoS attack. This means preventing the DoS attack patterns from propagating beyond the point where they were first detected by the Web service.

Recover and resume secure operation as soon as possible after a DoS.

It is particularly important that any planned performance degradations or orderly partial shutdowns not be extended to any of the service’s security functions or self-protections. If the DoS attack becomes too persistent, or its propagation cannot be prevented, the entire Web service should shut down in a safe, secure manner. Unless a service is mission-critical as defined by organizational policy, it must never be allowed to continue operating without fully-operational security functions and self-protections.

The service should also be designed and implemented to transition to a fallback state if it detects that any of the external mechanisms it relies on to accomplish its security functions (e.g., SAML Attribute Authority, PKI components) become unavailable.

The following approaches to the design, implementation, and sustainment (operation and maintenance) of the Web service will increase its ability to recognize, resist, and recover from DoS:

Design to include redundancy of critical functions, with diversity of how those critical functions are implemented.

Design exception and error handling capabilities that:

Use defensive programming techniques and information hiding to make the Web service software more robust.

Through QoS and reliable messaging, Web services can ensure that messages are not lost even if the network is saturated.

Web services, due to either their implementation or that of the frameworks on which they depend, may begin to degrade through residual cache data, temporary files, or even a fragmented hard drive. To prevent availability risks due to this degradation, it is useful to perform periodic software rejuvenations and reconfigurations to return the service software to a known reliable state.⁵¹ The techniques used vary among OSs and applications. Rejuvenation is common in organizations taking advantage of virtualization, because it can be performed by taking virtual machine snapshots and reverting back to them after a period of time.

Organizations deploying and implementing Web services should also be aware of two of the most common accidental threats against availability: service recursion and service deadlock. Through Web services’ support for dynamic discovery and binding, it is possible that a single Web service may attempt to bind to itself, possibly resulting in a DoS. Deadlocks are an equally important threat that arises when multiple entities are requesting access to the same resource.

One of the primary goals of a distributed system is the ability to recover when a node in the system fails. Through dynamic discovery and binding, Web services can be designed to recover if a single service fails, whether the failure is accidental or intentional. UDDI supports listing multiple URIs for each Web service. When one instance of a Web service has failed, requesters can use an alternate URI.

Using UDDI to support failover causes the UDDI registry to become a single point of failure. To remedy this, UDDI supports replication. Through replication, UDDI registries can support multiple nodes, where each node is an instance of the UDDI registry. This way, backup nodes can be used when an individual node is faced with a DoS attack.

Most Web services deployed do not provide guarantees for QoS. QoS defines what the expected level of performance a particular Web service will have. By prioritizing traffic, overall performance of the system can be improved, allowing the system to make informed decisions when faced with few resources. For example, a Web service operating on a saturated network may use prioritization to allow only the highest priority traffic to be processed while letting the other traffic wait until network traffic returns to normal.

Standards are beginning to be developed and released to support availability of Web services. In particular, two competing standards are available that provide reliable messaging support: WS-Reliability and WS-ReliableMessaging, discussed in Section 3.8.3. Standards and techniques for providing QoS, detecting, resisting and recovering from DoS attacks are still under development. Sections 3.8.4 and 3.8.5 discuss two common design or implementation defects that can lead to a loss of availability without the malicious intent: deadlock and recursion.

The standards state that other QoS parameters, such as rate of failure or average latency, are out of scope because they are usually dealt with by lower layer protocols. For Web services to truly support QoS, existing QoS support must be extended so that the packets corresponding to individual Web service messages can be routed accordingly.

The WS-Reliability and WS-ReliableMessaging standards provide guaranteed message delivery using one of the following semantics:

At-Least-Once semantics, which is a guarantee that a message will be delivered.

At-Most-Once semantics, which is a guarantee that a duplicate message will not be delivered.

Exactly-Once semantics, which is a guarantee that a message will be delivered without duplication.

In addition to the message guarantee semantics, both standards provide a mechanism for sending messages in order. These features are crucial for critical applications that may rely on Web services. Previously, implementers would have to develop their own reliability mechanisms, which could prove costly or ineffective in practice. With the advent of these standards, robust implementations can be developed and used in the development of reliable Web services. Nevertheless, the existence of two competing standards makes it difficult for organizations to fully adopt either standard.

Deadlock is a condition that occurs when two processes are each waiting for the other to complete before proceeding. The result is that neither process can continue. Deadlocks can occur whenever the following four conditions are present in a system:

Mutual exclusion. A resource can only be accessed by one process at a time.

Hold and wait. Processes already holding resources can request more resources.

No preemption. Only the process holding a resource has the power to release it.

Circular wait. Processes form a circular chain of waiting.

Ideally, either the programs that experience deadlock or the underlying operating system would be able to automatically detect and recover from the deadlock, but it is difficult for individual systems in a SOA to detect deadlocked SOAP requests. SOA environments are susceptible to both local and distributed deadlocks. In a local deadlock, a provider is poorly designed and has an internal deadlock preventing it from returning a response to the requester. In a distributed deadlock, one Web service that is not responding may lead to the entire choreography stalling until an administrator notices.

If deadlock occurs, multiple requesters could have their requests blocked indefinitely and could cause the clients awaiting the responses to suspend all other activities until the responses are received, thus rendering them unavailable to their users. Because Web services can be sequenced (i.e., a provider responding to one requester sometimes needing to act as a requester of services from another provider), the probabilities of a circular chain of waiting are increased. A deadlock may also occur if one of the systems in a circular chain of waiting crashes during a request, leaving some systems endlessly waiting for a response.

Similar to a deadlock, Web services can also experience an infinite recursion, where Web services keep initiating requests to one another to solve a problem. For example, Web service A implements a service by forwarding it to Web service B, and Web service B searches the UDDI registry to dynamically bind a Web service that performs the required functionality and finds Web service A, so it forwards the request back to Web service A. Because neither Web service implements the required functionality, they will continue to send requests until they run out of resources. Such a situation needs to be carefully avoided, which may be difficult in a highly dynamic SOA.

Execution flow diagrams are the method development teams usually use to mitigate deadlock and recursion. These diagrams are fairly effective for predicting interactions within a single application. The interfaces from the Web service under development with other services, especially those provided by third parties (COTS, Open Source Software [OSS]), are more difficult to manage.

At the design level, service interface information for third-party services needs to be thoroughly reviewed so shortcomings can be effectively mitigated in the Web service design. At the design level, the most effective antideadlock mechanisms are to implement asynchronous (non-blocking) service-to-service calls and to design the Web service to use message buffering.

UDDI provides a medium for publishing and locating Web services. Originally, UDDI’s main focus was the Universal Business Registry (UBR), a publicly accessible directory of Web services. Most Web services are not for public use, so the UDDI specification expanded to include private implementations of the UDDI registry. A private UDDI registry provides a mechanism for internal applications and users to discover and access Web services within an organization with little, if any, human interaction. UDDI v3 was approved as an OASIS Standard in 2005, but as of this writing a number of UDDI registries implement UDDI v2, so UDDI v2 is also discussed. The following subsections provide additional details into the structure, operations, and security inherent to UDDI, as well as explanations of the APIs relevant to UDDI.

UDDI registries provide information about organizations and the Web services they provide through three different interfaces:

White pages, which provide the identity and contact information of an organization

Yellow pages, which divide organizations into categories and provide information about their services

Green pages, which provide information about an organization’s services: the locations of services, and binding information.

There are six data types in a UDDI registry that provide all the information:

businessEntity. Holds the name, address, and contact information of an organization

businessService. Holds technical data about what services and products the organization offers

bindingTemplate. Provides details on a particular Web service offered

tModel. Defines how to interact with the target Web service, which is usually done by providing a technical specification, such as a wire protocol, interchange format, or interchange sequencing rule (e.g., WSDL document)

publisherAssertion. Describes the relationship between businessEntity entries

subscription. Describes a request to monitor changes to certain entities within the registry.

A WSDL document provides requesters with all the necessary information to send SOAP requests to a provider service. A WSDL document defines services as a collection of endpoints, which are referred to as ports. It also provides an abstract description of the types of messages and operations a Web service performs along with what inputs are required for each operation and as what format the result is returned. A UDDI registry provides a method to search for Web services and provides requester services with the location of the WSDL document for the target Web service.

UDDI registries are generally hosted within organizational boundaries and allow access to certain services within an individual SOA to be restricted. There are four types of private registries:

Internet-based services registry. Hosted by a group of organizations and provides information about these organizations for public consumption

Portal registry. Resides outside of an organization’s firewall and provides information about that particular organization’s Web services

Partner catalog registry. Resides on an internal network and provides information on the services offered by a particular organization and its partners

Internal services registry. Resides on an internal network and provides information on the services offered within that network.

In addition, UDDI v3 provides a framework for access privileges to keep portions of the registry available only to authorized users.

In UDDI, the process of locating Web services through a registry is referred to as discovery. There are two types of discovery: direct discovery and indirect discovery. In direct discovery, the information is retrieved through a registry maintained by the service provider. In indirect discovery, the information is retrieved through a third party registry.

UDDI provides three SOAP-based APIs to access the registry:

A publishing API is used to place information into the registry. The publishing is restricted, so publishers must be authenticated. Authentication can be performed using a username/password combination, SAML, Kerberos, or some other method.

An inquiry API provides read-only access to the registry. The inquiry API allows Web services to search for organization details, services offered, and binding information for the services. This API is usually publicly accessible. In UDDI v2, the inquiry API does not support authentication, but in UDDI v3, authentication can be required for inquiries—limiting access to the registry only to trusted Web services.

UDDI v3 introduces a new subscription API that provides notifications about additions or updates to the registry. The subscription API is also restricted, requiring authentication by the registry.

In addition to the SOAP-based APIs, many implementations of UDDI registries provide a Web interface for publishing to and searching the registry. Because this is not part of the UDDI standard and is not implemented by all UDDI registry vendors, these UDDI Web interfaces are not covered in this guide.

As described in Section 3.9.2, some portions of the UDDI API require authentication. SOAP over HTTPS is usually required to make certain that publisher credentials cannot be intercepted during transmission. In addition, all publishers should be designated as Tier 1 publishers. In UDDI v2, Tier 1 publishers have defined restrictions for what services they can publish to the registry. In a private registry, these restrictions can vary based on the needs of the organization. In contrast, the specification does not require restrictions on a Tier 2 publisher.

Some UDDI registries provide the ability to restrict publishers’ activities at the account level, which provides some control over Tier 2 publishers. UDDI v3 provides the ability to define policies, which provide finer control over publishers than the Tier model available in v2. UDDI v3 adds support for XML Signatures to the registry, providing a way for inquirers to verify the integrity and publisher of data in the registry. In UDDI registries, a publisher is only allowed to alter entries the publisher created, so inquirers can be reasonably certain that any changes made to an entry in the registry were made by the appropriate publisher. Nevertheless, even with digital signatures, there is no guarantee the information in a UDDI registry is correct—only that it was published by a trusted entity.

The inquiry API is used to search for Web services within the UDDI registry that meet the requester’s needs. In UDDI v2, the inquiry API is accessed through SOAP over HTTP and requires no authentication. The requester must have a pre-existing trust relationship with the UDDI service, which can be achieved by accessing a private UDDI registry within the organization or a trusted public UDDI registry (e.g., the UBR). Most UDDI registries run from a functioning Web server and are unaware as to whether or not the Web server is using HTTPS. It may be possible to configure a UDDI v2 registry’s inquiry API to use SSL/TLS, which in turn can be configured for authentication in addition to encryption.

UDDI v3 specifies that the inquiry API can be accessed over HTTPS and supports authorization. If a UDDI v3 service is being used with authentication, the requester has previously established a relationship with the registry and can likely trust its results. In UDDI v3, authentication usually consists of a username and plaintext password transmitted over SSL/TLS, but the UDDI specification states that any authentication method can be used to access the registry, from X.509 certificates to SAML assertions. Also, because UDDI v3 allows the inquiry API to use SSL/TLS, the requesting service can be certain that the results from the registry were not tampered with during transit.

In UDDI v2, there is no way for the requester to verify the integrity or origin of data retrieved through the registry. Some integrity assumptions may be made because publishers are required to authenticate to the registry, but it is not possible to determine whether or not a particular publisher is legitimate.

In UDDI v3, all data entries stored in the registry can be signed using XML Signatures. After receiving information about a candidate, the requester can retrieve the public key associated with the candidate and verify the integrity of the data from the registry. This is the best solution for verifying that entries in a UDDI registry are valid.

In UDDI v2, it is possible to include digital signatures for entries in the optional “description” element of each data type, as this element is designed to contain textual information about the entry. Both the requester and the publisher must agree on a protocol for performing this type of signature so that verification can be possible.

The publishing API is used to publish information about a Web service in the UDDI registry. According to the UDDI specification, SOAP over HTTPS should be used exclusively for all calls in the publisher API. In addition, the publisher must authenticate with the UDDI registry via the “get_authToken” call. All calls within the publisher API require the authentication token to be passed as an argument.

The UDDI specification does not define what authentication methods should be used, so they can range from a simple username/password combination to a SAML assertion, depending on the implementation. Once the publisher has received the authorization token, it must be kept securely until it is has been discarded so that an attacker cannot use the token.

In a UDDI registry, there are limits for how much each publisher can publish. In UDDI v2, the limits are broken up between Tier 1 publishers and Tier 2 publishers. Tier 1 publishers are limited to publishing a hard-coded number of UDDI entries.⁵² Tier 2 publishers have no hard-coded limit and they are to be strictly monitored by the UDDI registry’s operator. In UDDI v3, operators have more fine-grained control over the limits imposed upon publishers through policies.

A requester can independently verify the validity of these structures using the UDDI API. In UDDI v3, an additional method for verifying the publisher of any data structure is an XML Signature. When using a UDDI v3 registry, XML Signatures should be used, as they are the best method for verification. If signatures are to be used in a UDDI v2 registry, it may be possible to place them in the description element. The publisher and the inquirer must have a predefined method for calculating signatures in this case.

Publisher assertions are used to establish a relationship between two businessEntities, such as one entity being a subsidiary of the other. For a publisherAssertion to be recognized by the UDDI registry, both entities must create the publisherAssertion. This allows inquirers to be certain that there is a relationship between two entities.

The publisher is also responsible for verifying that the records and assertions published are correct. Any mistake made while publishing will result in incorrect results when inquirers access the UDDI registry.

While UDDI provides a registry for searching for and automatically connecting to Web services, there is no mechanism for describing how to connect to candidate services. This is done through the WSDL document. A Web service’s WSDL document is referenced through the bindingTemplate and tModel data structures.⁵³

When publishing a Web service, a UDDI publisher must make certain that there is a tModel associated with the WSDL for the Web service being published. These are referred to as wsdlSpec tModels. wsdlSpec tModels allow inquirers to locate Web services that correspond to the same published WSDL document. For example, there are standard WSDL specifications for UDDI and NCES services, but there may be multiple Web services that implement them.

tModels are referenced from the bindingTemplate data structure by providing a tModelInstanceInfo entry for each tModel that corresponds to the service’s WSDL document. A tModel provides the location to a Web service’s WSDL document, but the bindingTemplate’s accessPoint element specifies the location of the Web service itself. UDDI allows for Web services and WSDL documents to be in separate locations.

Once the requester receives the WSDL document for the candidate Web service, it must be validated. The simplest method for doing this is to provide a digital signature of the WSDL document for the requester to use. WSDL v1.1 does not provide an internal mechanism for signing WSDL documents. Until such a mechanism is available, the candidate Web service should provide an external signature for the WSDL document or the requester should independently verify via out-of-band communications that the site providing the WSDL document is a trusted entity.

Requesters cannot connect to most providers without some form of authentication. WSDL v1.1 does not provide a method for specifying the security requirements of a Web service. Future versions of WSDL are slated to have this feature. At the moment, the requesting Web service must use some external method for determining what authentication requirements a candidate service has. This can be done using tModels.

In a UDDI registry, a bindingTemplate structure can hold zero or more references to tModels. tModels are used to represent the different WSDL service interfaces, but may be used to reference other metadata related to the Web service.

Because tModels are used to describe the particular interfaces and behavior of a Web service, an additional unique tModel could be developed for each method of authentication that Web services in the registry may use. When a requesting Web service sees this tModel, the requester will know what methods of authentication the candidate Web service requires. This approach is implemented for the NCES service discovery services.

Web service security standards are developed and maintained by several different organizations: W3C, OASIS, Liberty Alliance, and an industry forum headed by Microsoft and IBM. Some industry forum specifications, such as WS-Security, are submitted to OASIS for maintenance and acceptance as a standard. In contrast, other industry forum specifications directly conflict with OASIS or W3C standards, like the WS-Reliability and WS-ReliableMessaging standards. Where such conflicts exist, one or more of the involved standards may change or cease to be implemented. Organizations should take care when adopting such overlapping standards to avoid expensive upgrades or overhauls of the SOA.

The WS-Security specification provides confidentiality, integrity, and non-repudiation using the XML Signature and XML Encryption standards. It also supports authentication via SAML, X.509, Kerberos, REL, and username and password combinations. WS-Security should be employed as an integral part of any organization's Web services deployment, but it does not secure the entire SOA. For Web services that were not implemented with support for WS-Security, XML gateways can be used to act as intermediaries and apply WS-Security to SOAP requests and verify SOAP responses, using HTTPS to secure communication directly between the legacy Web service and the XML gateway. While confidentiality and integrity can be assured via WS-Security, there are no established standards for specifying the required QoP of a particular SOAP message or Web service. By sharing the QoP information about individual Web services, requesters and providers can support dynamic binding in a secure environment.

WS-Security provides a powerful framework for authentication within a single organization. For authentication within large organizations or across multiple organizations, using a single TTP may not be feasible. To facilitate authentication across trust boundaries, a trust federation framework should be adopted. Organizations face several options: Liberty Alliance, WS-Federation, and Shibboleth. Liberty Alliance works closely with OASIS, and SAML v2.0 incorporated many of the features from earlier Liberty Alliance specifications. Because the same functionality is provided by each framework, the choice may largely depend on whether COTS products already deployed support one of these frameworks.

Distributed authorization is becoming increasingly common in organizational SOAs where each Web service is a PEP that communicates with a PDP to get authorization information. To this end, SAML and XACML were developed to provide support for multiple authorization models. SAML assertions are generated by TTPs and can be used as security tokens by entities within the SOA. When a request is received, PEPs use the SAML protocol to communicate with the PDP to determine whether the requester is authorized. XACML provides a flexible, extensible policy language and mechanisms for querying XACML policies. Similarly, authorization rules may affect individual content or services. Security metadata can be used to determine what entities are authorized to access content or services. By providing policy along with the content or service, PEPs are able to make some authorization decisions without communicating remotely over the network.

Securing the discovery process is also important for an organizational SOA. If the registry can be corrupted, or if the provider's WSDL document is wrong, an attacker may gain access to restricted information or the entire SOA may fail. UDDI v3 provides support for digitally signing registry information using XML Signatures, allowing requesters to verify the authenticity and the integrity of the information. WSDL documents, however, do not inherently support digital signatures, meaning that verifying the authenticity and integrity requires an out-of-band mechanism. True automated discovery is still hampered by the fact that even though an individual's identity is trusted, the published service may be malicious or may itself use a malicious service.

Some of the biggest challenges facing Web services are in the realm of accountability and availability. While XML Signatures and the algorithms defined in FIPS 186-2 can be used to support non-repudiation, accountability also requires the use of auditing. There is no standard for distributed auditing within a Web services environment. NIST SP 800-92, Guide to Security Log Management⁵⁴ provides guidance on managing security logs within an organization, but any portion of a SOA transaction outside of the organization's control may not retain security logs.

Availability is increasingly becoming a concern with Web services, so QoS is becoming increasingly important. For mission critical applications to be built with the SOA paradigm, the SOA must be able to withstand one or more services becoming unavailable, either due to a DoS or a failure. Web services’ support for dynamic discovery and binding allows for failover Web services to be accessed when a DoS occurs. Similarly, reliable messaging technologies can be used to ensure that messages will be received in spite of a DoS attack. Finally, QoS technologies can be used to prioritize Web service traffic so that high priority Web services will still remain functional in the face of an attack on the availability of the network.

A Web portal is a starting point for Web activities. By logging into a Web portal, a user is granted access to the information and services connected to the authenticating portal. Common implementations for portals are Internet search engines that expand into information centers, and Web interfaces for corporate knowledge management systems.

Web portals that sit at the boundary of a SOA have multiple roles: a Web server for users and a requester to other Web services in the SOA. This dual role brings with it security implications that could impact Web services interacting with the portal. Some of these implications include:

Authentication. Who is sending this message?

Authorization. Is the authenticated subject entitled to access?

Audit. Can it be proved that this transaction occurred?

Integrity. Was the message, or the system, tampered with?

Confidentiality. Can the information be read while it is in transit? In storage?

Privacy. Can personally identifiable information be released to the public?

Availability. Is it vulnerable to a denial of service attack (brute force or otherwise)?

Non-Repudiation. Can it be proven that the sender and the recipient did in fact send and receive the message?

Policy Administration. How easy is it to apply or change a security policy rule or configuration parameter?

Additionally, Web service faces many challenges to fulfilling these basic security requirements. The threats to Web services security include both the traditional exploits associated with the underlying protocols such as HTTP, as well as new threats associated with new protocols and services, such as SOAP and XML.

This section expands on the information provided above, with particular focus on explaining the role of proxy agents, authorization and access control considerations for portals, and potential mechanisms for enforcing XML filtering constraints on content provided to portal users.

As mentioned above, Web services that reside on the edge of the SOA are used to represent users during communications from the client on the edge of the service and other Web services. A number of Web service invocations are at the request of users through edge applications, such as portals, Web servers, and single sign-on servers. These edge applications are server-based Web applications that interface, as proxy agents on behalf of the user, with the Web services in the SOA. All security functions that require direct interaction with users (via their clients) are expected to be performed by the edge applications. The Web services connected to the portal would then presume that when the edge applications assert a user’s authenticity and privileges, such an assertion is trustworthy.

For Web services to communicate, the interacting parties must trust each other. When communicating using Web services, there are a number of different entities involved: the client application through which the user operates, a portal, a requester, a provider service, an SSO server, and SAML-enabled Web applications.

Figure 4-1. Web Services Trust Relationships

In a Web services trust environment, a user will communicate with an SSO server and one or more SAML-enabled Web applications, as shown in Figure 4-1. For this SSO environment to function correctly, all three entities must trust each other. A user may also access a portal application, which provides Web service proxy agents access to providers on behalf of the user. In addition, requesters will often talk to providers on their own behalf. For all of these interactions to function, the entities involved must trust one another. WS-Security enables two Web services to trust each other, while SAML enables one entity to assert that it trusts another entity. In this type of configuration, it is possible to build a chain of trust, where a Web service trusts another Web service regardless of the fact the two Web services have no direct relationship.

A portal may use SAML assertions to express a user’s identity to other Web services, so SAML assertions may be extended into authorization and access controls. Portals can be implemented using one of the available Liberty or SAML libraries or using one of the many COTS products that will act as an identity server. By implementing an identity server, the portal’s presentation functions are combined with the SSO and distributed access management services, providing only authorized information to be presented to the user.

COTS identity servers provide robust support for the complexities of the SAML specification. Additionally, most COTS identity providers support a wide variety of authentication mechanisms—from certificates to passwords. While these are designed to prevent attacks at the protocol level, COTS identity providers must be configured correctly to be secure.

As described in Section 4.2, pages presented to the user can be tailored to analyze a user’s credentials to prevent users from searching for services that the user is not authorized to interact with.

If a portal’s SAML assertion (on behalf of a user) does not include the proper credentials to access a service (as determined by the discovery service), the user will not be permitted to know that the service exists. Controlling access to services at the discovery level may be beneficial to the service. It can simplify the administration of access controls required to maintain the service’s expected level of security.

In a SOA, the Web portal is an SSO starting point for users interfacing with a SOA. Web portals interact with provider services and identity providers to perform actions on behalf of the user. By acting as a middleman between the user and the provider services, portals must provide authentication information about the user, coordinate with the provider's authorization mechanisms and policy administration as well as provide auditing services, integrity, confidentiality, availability, and non-repudiation of messages sent to both the user and provider. Through SAML and WS-Security, these goals can be achieved. SAML allows the user to authenticate with the identity provider and will provide SAML assertions that can be sent along with all requests on behalf of the user. Provider services can then verify the contents of the SAML assertions and determine whether the user is authorized to perform the action.

Migrating applications to Web services can expose the legacy application and backend databases to new threats that were not considered when the applications were initially developed. Securely enabling Web services on legacy applications requires customized Web service adapters to be securely coded and implemented. Like any Web service, these adapters must be resistant to attack. Authentication, authorization and access control are among the first concerns to address when migrating a legacy application to a Web service architecture.

Web applications are typically designed for client-server communication. SSL/TLS allows both the client and server to authenticate their PKI certificates, yet in most situations, Web servers are not configured to authenticate clients’ SSL/TLS certificates. Instead, they rely on less strong authentication, such as a username and password. Authenticating both the client and server certificates can allow for strong authentication between Web services. Authentication using Web service technologies can be achieved using WS-Security as described in Section 3.1.2.

To Web service-enable a standalone legacy application using its own proprietary authentication mechanism requires some mechanism for mapping Web service credentials to their associated legacy credentials and an adapter for mapping incoming or outgoing Web service messages to the legacy application’s protocols. Typically, these credentials are in the form of a username and password combination; in some cases, these are stored or transmitted via an insecure encryption scheme. The legacy adapter should encrypt and securely store the legacy credentials when they are not in use. In addition, the adapter connection to the legacy application should be secured using technologies like SSL/TLS or IPsec.

Whenever possible, legacy adapters should not be developed from scratch. A robust, well-tested third-party product is likely to be more secure and reliable than a from-scratch adapter. There are a number of COTS products (e.g., middleware solutions) capable of integrating with legacy applications.

Regardless of how the Web service-to-legacy adapter is implemented, it should include logging sufficient to satisfy the audit and reporting requirements discussed in Section 5.5. Ideally, the Web service and legacy application should support a single authentication method throughout the end-to-end solution.

If the legacy Web application performs its own user authorizations (rather than relying on a centralized authorization service provided by a portal or SSO server), the application process that allocates permissions and privileges to users and processes must be correct and unable to be subverted. The authorization process will have to trust the authentication system’s assurance that the users and processes to be authorized have already been properly authenticated.

If the authorization information used by the application will be stored and managed in a directory (for example, the LDAP or X.500 directory used by the PKI), the transmission path over which authorization information will be sent from the directory to the application’s authorization process should be secured. When the authorization data is stored in the directory, it should be protected by the directory’s access controls and, when feasible, by encryption.

If standard user/group/world authorizations are inadequately fine-grained, the application’s authorization system may have to implement its own access control mechanism (Section 3.5.1 discusses access control models).

Because of the additional requirements for access control for systems that contain or process sensitive information, it may be necessary for such applications to augment the underlying file system’s access controls by ensuring that the data that require additional protection are encrypted when they are written by the application to a file system directory (or database). In practical terms, encryption of data at rest is a form of access control: access to the encrypted data is controlled by limiting access to the cryptographic keys required to decrypt that data.

The application’s design should implement separation of duties, roles and privileges for subjects as well as minimize the resources needed by the application process. When designing the application, the actions that any component will be allowed to perform should be explicitly specified. Custom processes and scripts should not be granted or allowed to retain privileges that would enable them to perform actions not expressly defined for them. Instead, each process in the application should be designed to do the following:

Perform only the actions explicitly defined

Strictly enforce the processing order defined

Call only those other processes and libraries absolutely needed to invoke

Execute only one task at a time

Initiate a new task only after the previous task has completed

Access only data absolutely needed to successfully perform tasks.

Allowing non-Web applications such as database and directory server applications to securely interact with Web services involves many of the same measures as enabling Web applications. The same procedures are used for creating a Web service and extending an existing application’s functionality as a discoverable Web service.

Web services can extend any application, as long as there are robust and easy-to-use business objects or an API built into the application. It will be more difficult to Web service-enable applications that have business logic built into the graphical user interface (GUI), because the business logic must usually be rewritten to accommodate the new Web service extension of the business object.

Both SSL/TLS and WS-Security, the primary methods for securing SOAP messages, rely on PKI certificates for authentication. Many legacy applications only support username and password authentication over time. Organizations may benefit from transitioning these legacy applications to PKI authentication. Initially, the legacy application should provide the capability for users to test their certificates while maintaining username password access. Then, the application should allow users who have certificates to authenticate using these certificates while still allowing users to authenticate with their existing usernames and passwords. Once users have become familiar with certificate-based authentication, the application should publish a date after which usernames and passwords will no longer be accepted. In the transition to Web services, an API should be developed that can be used to communicate with the discovery service as well as authenticate users.

For applications with a large number of current users, an applet can be written to establish a mapping between an existing username—and associated privileges—and a subscriber certificate. The first time each user is authenticated based on the certificate, the user will be asked to provide the old username and password. The applet will then establish the mapping of the privileges associated with that username to the new certificate, so that the next time the user logs in, those privileges will be granted based on the certificate presented, without the user being required to enter the old username and password.⁵⁵

In accordance with the security functions provided by authorization and access control measures, sound Web services security practices also include the maintenance of auditing records. Auditing should be done to maintain appropriate accountability for legacy application transactions in the Web services environment.

The legacy application’s auditing mechanisms should be developed to provide sufficient information and secure storage for audit data. Verbose logging is beneficial to later analysis of the system. Appropriate review procedures can identify anomalous access control situations, which may indicate an attacker’s presence. To support analysis, logs should be stored securely for an appropriate length of time, which is usually determined by the organizational policies. NIST SP 800-92 provides guidance for managing logs within an organization.

When a database application is exposed as a service or is simply accessed by a Web service, the security of the database relies entirely on the security of the applications directly accessing it. The exposing application should account for confirming the requester’s authorization to access the database. Additionally, the application must filter requests before forwarding them on to the database. Incoming requests may include SQL injection attacks or other attempts to subvert the database or retrieve sensitive information. The application must also filter the data before providing it to the requester to prevent unintentional leakage.

When integrating legacy systems as backend servers in a SOA, developers must make sure that security does not stop at the connection between the SOA and the Web service interface to the legacy system. Instead, the developer should incorporate the following measures to ensure the integrity of the data being processed:

Establish end-to-end user authentication. Set up an end-to-end user authentication mechanism that reaches from requesters to the mainframe or other backend legacy server.

Establish an end-to-end encrypted data channel. Use encryption from the individual requesters to the Web service interface and from the Web service interface to the legacy backend system. This is done to ensure that sensitive data are not exposed in transit over external and internal networks. If the backend system does not natively support encrypted data channels, IPsec or SSL tunneling software can provide an encrypted data channel.

Implement public key security end-to-end. Deploy public key components all the way from the requester to the backend system and integrate them with existing security systems.

In addition to certificate-based identification and authentication (I&A), the Web service will also need to perform application-level monitoring and auditing of Web connections, access events, and security violations.

In certain high-risk environments, a second factor of authentication, in addition to PKI certificate-based I&A, may be desired. This second factor may include a static password, a dynamic password, or a biometric. In some applications, the user’s initial authentication may be via a second-factor mechanism during the authenticated session.

Security for the mainframe was not designed with the SOA processing model in mind. Rather, mainframe security was designed for a closed, well-defined, and tightly controlled environment. Key characteristics of such environments include a known and relatively trusted user population, a well-defined set of applications, and firm connectivity boundaries. Application developers need to leverage existing backend mainframe security systems.

Secure Web service-enabling of legacy applications allows new SOA applications to leverage the functionality and services provided by an organization’s legacy systems. This can prove to be cost-effective when developing Web services that require legacy functionality. Web service-enabling legacy applications can introduce Web service threats to the legacy application and provide a new avenue of attack into the legacy application. Legacy applications built without understanding of SOA or networking may lead to the discovery of new vulnerabilities in the application. When Web service-enabling a legacy application, it is important to be aware of these threats and use appropriate technologies to mitigate them. Similarly, the mechanisms used to Web service-enable legacy software must also be secure, to prevent introducing new vulnerabilities into the system.

Ideally, legacy applications should be modified to support Web service standards, but this may not always be possible. If the application was originally designed as a Web application, it can be configured to use SSL/TLS for authentication, confidentiality and integrity between the Web service front-end and the application itself. In addition, many legacy applications have built-in authentication and authorization mechanisms. If possible, these should be upgraded to support SOA technologies; otherwise the Web service front-end will have to map SOA identities and permissions to those used by the legacy application. While it is important to provide an updated authentication and authorization mechanism, it is equally important to take advantage of logging facilities provided by the application. In addition, these logs should be integrated into the system-wide log management infrastructure. By exposing legacy functionality as a Web service, there are a number of potential attacks that may surface, requiring the Web service front-end to be carefully designed, implemented, and deployed to take full advantage of the legacy application's security functionality while providing the security needed to protect against threats introduced by the SOA.

When implementing a secure Web service, developers should be aware of how to use the available development tools, techniques, and languages in a secure manner, in addition to implementing the security functionality already discussed in this guide. While security functionality is an important aspect of secure Web services, security functionality can be compromised by poorly implemented software. See Appendix A for a discussion of some attacks to which Web services are susceptible. The following sections outline the various developer toolkits, XML parsers, available development languages, and security testing methodologies that can aid in testing a Web service.

When choosing an appropriate Web services developer toolkit, it is important to first determine whether there are any language requirements of the Web service. Should it be able to interact with a .NET environment, a Java environment, or natively compiled libraries? In most cases, either a Java or .NET Web service will be able to meet all of the functional requirements of the system, but there are times when a Web service written using C or C++ may be necessary. If the language requirement is not an obstacle, there are further attributes of a Web service development toolkit to consider.

The most important aspect of a Web service development toolkit is its ability to interoperate with Web services developed using other toolkits. The SOAP and WSDL specifications developed by W3C left some design choices to individual Web service toolkit developers, making Web services less interoperable. In particular, by default Java and .NET Web services may not be able to communicate with one another. To this end, WS-I developed WS-I Basic Profile 1.1, which specifies exactly how the WSDL and SOAP specifications should be implemented to achieve full interoperability. Toolkits that support WS-I Basic Profile 1.1 will be able to interoperate with Web services from other toolkits with—at most—only minor changes to the Web service being developed.⁵⁶

Additionally, WS-I is working on WS-I Basic Security Profile 1.0, which will allow Web services to implement interoperable authentication mechanisms. WS-Security implementations do not always interoperate well with other Web services, so the WS-I Basic Security Profile will aid in developing secure interoperable Web services. As this specification has not yet been ratified, few (if any) Web service toolkits support it. Until the WS-I Basic Security Profile has been released by WS-I, toolkits should be used that provide support for (or have libraries available for) the WS-Security and SAML specifications, which are the most commonly used tools for securing and authenticating Web services.

Finally, WS toolkits should ease the burden placed on the Web service developer by providing tools that will create stubs, the Web service-specific code, that the developer can use without having to delve into XML or SOAP specifics. Usually, these tools are in the form of a command-line program that will take either a pre-existing application and develop the WSDL or develop stubs from a pre-existing WSDL.

XML parsers are the first portion of a Web service that process input from other Web services. A poorly designed or poorly configured XML parser can be used to compromise the Web service regardless of how secure the Web service is. To this end, it is important to use robust and proven XML parsers.

An improperly configured XML Parser is susceptible to several attacks:

Large or recursive XML documents can overload the XML parser and lead to a DoS.

XML documents can be configured to refer to and use local files. This can lead to an attacker gaining knowledge about the local system.

External references to other XML documents or XML schemas can be used to bypass XML validators.

All of these XML parser security concerns can be overcome by properly configuring the system. In particular, oversized XML documents can be prevented by configuring the Web server on which the Web service is running to only accept messages up to a certain size. When the oversized XML document is passed to the Web server, it will prevent the entire document from reaching the Web service. The other XML attacks can be prevented by developing robust local XML schemas for the Web service and configuring the XML parser to validate all incoming XML traffic against the local schemas rather than against remote schemas provided by the incoming traffic. Additionally, one of the main functions of an XML gateway is to provide a robust defense against XML attacks that target the XML parser; XML gateways provide a robust system for detecting and validating XML traffic before it reaches the Web service and can be configured to notify appropriate personnel when such an attack has been attempted.

Each of the languages discussed in this section has its own set of sound security-related practices, but all benefit from a common set of secure coding practices that include the following:

Do not include sensitive data in user-viewable source code (i.e., Web page code that can be displayed by the user using the view source function of his/her browser) or configuration files.

Assemblies that support untrusted or partially trusted callers should never expose objects from assemblies that do not allow untrusted or partially trusted callers.

Allow untrusted or partially trusted callers only after the developer has carefully reviewed the code, ascertained the security implications, and taken the necessary precautions to defend against attack.

Disable tracing, debugging, and other diagnostic development or testing-related functions, tools, and hooks before application deployment.

Do not issue verbose error information to the user.

The procedural languages summarized in the following sections are considered to be relevant to Web service design and development. This does not preclude the importance or relevance of other languages that are not explicitly described; rather, these are the languages most commonly used to implement Web services.

There are many cases where Java, .NET, or other forms of managed code are not practical, even when implementing Web services. In particular, Web services based on C and C++ do not require the overhead of a framework to implement Web services specifications. Java EE and .NET can take up hundreds of megabytes of space, which may not be available on a particular system (usually a legacy or embedded system). When adding Web service support to legacy systems, Java and .NET may not be available, as .NET does not run on versions of Windows older than Windows 2000, and there may not be a Java Virtual Machine for the legacy system’s platform or operating system.

To this end, there are a number of Web service frameworks available for C and C++. Web services developed using these frameworks do not have the security benefits provided by managed code such as .NET and Java, so they must rely on operating system-level security support such as restricting user permissions and running the Web service within restricted environments. It is important to ensure that all code is properly written to avoid the potential pitfalls of the language, such as buffer overflows. C and C++ Web services can be implemented without much of the complexity of a Java or .NET Web service and would not be susceptible to vulnerabilities associated with the framework itself. An additional step that can be taken to protect Web services developed in C or C++ would be to place the Web service behind an XML gateway, which would filter XML attacks and protect the C or C++ system from external entities.

Java runs in a secure virtual environment through the Java Security Manager (JSM), which provides a sandbox in which Java applications can run. Java also provides more stringent memory protections than C or C++, relying on garbage collection and references memory management in place of the more manual approach used by C and C++. Java allows the user to have almost full control of the virtual environment in which the Java bytecode is run. Java code intended for use on the client runs in a different environment, under a different trust model, than code on the server. There are common requirements, whether the Java code runs on the client or server. Input from untrusted sources should always be checked and filtered. Java code that inherits methods from parents, interfaces, or parents’ interfaces also inherits vulnerabilities in those methods. For this reason, it is critical that the developer use inheritance with caution.

Because the Java language is compiled into a platform-independent bytecode format, much of the information contained in the original Java source code remains in the compiled bytecode. This makes decompilation by attackers easier for Java than natively compiled languages like C and C++. Bytecode obfuscation is a technique designed to help protect Java bytecodes from decompilation. Preventing bytecode decompilation is a countermeasure both against disclosure and tampering (i.e., confidentiality and integrity concerns).

Java bytecode must be able to undergo bytecode verification, which gives it a measure of protection against malicious code, and it is not possible to distribute the bytecode in a more secure form. Application of digital signatures to the native Java code (code signing) is intended to increase the security of the distribution process by providing a means of verification by the execution environment that the received Java code came from a trusted source and has not been tampered with en route.

The technique most often proposed for reducing this vulnerability is code obfuscation. Code obfuscation transforms the Java program to make it more difficult to understand, yet functionally identical to the original. The program produces the same results, though it may execute more slowly or have other side effects because of the code added to it by the obfuscation technique. Thus, there are trade-offs that must be considered between the security provided by code obfuscation and the execution time and space penalties imposed on the transformed program.

There are a number of COTS and public domain programs and utilities for performing code obfuscation. Some of these apply optimizations to the Java compiler, such as array and loop reordering and procedure inlining. Code obfuscation can be classified according to the kind of information the obfuscation technique targets and how it affects that target.

C# was developed by Microsoft as part of its .NET initiative to provide developers with the power of languages like Java and C++ for rapid application development. Like Java, C# runs in a secure environment through code access security, which provides a sandbox in which to run Common Language Runtime (CLR) applications, such as C# and VB.NET. C# applications also benefit from a garbage collection system, preventing most memory leaks from affecting C# applications. C# provides a more type-safe environment than C++, but unlike Java, C# applications support accessing raw memory— although this requires certain code access security permissions to be enabled. .NET’s code access security offers security features similar to Java’s, such as code signing, stringent access control and sandboxing.

Visual Basic .NET was released alongside of C# as a successor to the legacy Visual Basic language. While the VB.NET syntax is similar to the original Visual Basic language, VB.NET provides a fully object-oriented language in place of the COM-based language of Visual Basic. While Visual Basic has some security concerns, VB.NET’s support of garbage collection, object-oriented design, code access security, and the .NET framework make VB.NET similar to C# and Java. Through the .NET framework and the CLR, C# and VB.NET have access to the same security libraries and both C# and VB.NET applications are subject to code access security.

As in Java, code written in C# or VB.NET can be downloaded and run from untrusted sources. To alleviate this problem, Microsoft has integrated code access security into the .NET Framework. Code access security provides varying levels of trust for code based on where the code originates and allows individual users to specify what permissions will be given to an application. Because code access security is part of the .NET Framework, all applications that access the .NET Framework can be subject to code access security. Because policies are defined on a per-machine basis, libraries are provided that allow applications to determine whether the application has a particular permission prior to performing a potentially restricted act—allowing .NET applications to alter their behavior rather than simply generate a security exception.

Content within SOAP messages is expressed in XML. Because of this, the security technologies used by Web services are based on those developed for XML. XML was designed so that it could be easily extensible and combined with itself. It should be natural to provide integrity, confidentiality and other security benefits to entire XML documents or portions of these documents in a way that does not prevent further processing by standard XML tools.

In general, most of the risks posed by XML are not unique. They can appear with many other technologies and systems, new and old. Some of the risks are more severe for XML than for older systems simply because XML is more expressive, flexible and powerful. Some of the risks derive from the ways in which XML is used (e.g., for metadata) and would appear whether using XML or some other technology.

Some recognized vulnerabilities and attacks specific to XML and XML Style Sheets (XSL) include the inability to:

Prove validity of XML content and originator. Not all XML parsers validate the URIs of entity references before accessing them

Prevent exploitation of XML entities to steal information. Because some parsers reference entities without first validating their URIs, it may be possible to inject references to other locations on the target server from which secret information could then be extracted

Prevent exploitation of XML entities to launch DoS attacks. Because some parsers reference entities without first validating their URIs, it may be possible to create DoS attacks by flooding the XML parser with illegitimate entity references

Enforce validation. An attacker may be able to subvert the validate command called by the XML application when it has loaded the schema cache with namespaces. Attackers do this by using a root element from a different namespace to redirect xsi:schemaLocation to point to their own schema, in which they include the declaration <xs:any namespace=##any,, processContents=“skip”/>.

Security testing in the Web services realm should be included in the overall test plan, and should be performed iteratively throughout the Web service’s lifecycle, not just after implementation or deployment. The characteristics of Web services make security testing more difficult than for more traditional applications. The Web services model provides a completely implementation-independent mechanism through which applications can interact. The tester can make no accurate assumptions about how that application software is built. Thus, the reliance on black box testing is much heavier than it is for other application testing. Testers must also rely heavily for their understanding of the software on its interface and system specifications.

The highly distributed nature of Web services technology creates a dependence on complex interactions, which must be testable. The tester will need to adopt new techniques and processes for many aspects of Web services security testing. Security function testing in particular will require greater use of distributed test agents and associated technology, comparable to how load testing is done.

How much security-focused testing is enough? Ideally, the tester would trace all paths through the code and all internal interfaces among components within the service and all external interfaces between the service and other services, and would try out every possible input to ensure it didn’t cause an unexpected security violation. Depending on the complexity of the service, testing every possible path, interface, and input may not be feasible. A more practical goal is to cover every path through each unit, and every inter-unit and external interface at least once.

Each of the categories of Web services security tests is discussed below.

Web Service Security Protocol Conformance Testing. This type of testing is generally performed by an independent testing organization on specific implementations of Web services security protocols by specific vendors in their Web service products, as well as some open source implementations. The objective of this testing is to ensure that individual protocol implementations conform to the relevant published standards from OASIS or W3C.

Correctness Testing of Web Service Security Functionality. This type of testing is focused on ensuring that the security functionality performed by a Web service meets its stated requirements.

Security Focused Unit Testing. This type of testing focuses on the smallest unit of the Web service application, such as individual classes or functions, apart from the rest of the application. Through unit testing, it is considerably easier to test all of the possible paths that attackers could take to reach unexposed methods or perform illegal operations.

Whole-Application Vulnerability Assessment. The objective of this testing is to seek residual vulnerabilities that appear in the Web service as a whole, as a result of the interactions between the service and other Web services, instead of tracking down vulnerabilities within and among individual unit components of a single Web service.

Web Service Software Security Assessment. This type of testing usually includes threat modeling, requirements risk analysis, and security modeling. Software security test techniques include security-oriented code reviews, security fault injection tests, fuzz testing, and penetration testing.

From a security standpoint, Web services adoption today is focused on the corporate intranet, with Web services used to simplify and reduce the cost of integration of existing applications and databases behind the firewall. Web services that communicate outside the firewall are showing up in pilot projects, but are typically limited to service interactions with trusted business partners and known IT organizations.

Given this current state of the art, three capabilities are important in the tools used for testing the security of Web services:

Generation and testing of SOAP and XML messages, with examination of both messaging interfaces and individual message format

Automatic generation of test plans from WSDL files containing metadata about the interfaces of the Web services to be tested

Simulation of the actions of both requesters and providers.

There is little automated tool support specifically designed for Web services security testing. This dearth is consistent with the relatively small number of automated software and application security testing tools in general. This said, current Web services security testers will need to rely on the somewhat more prevalent software security testing and application vulnerability assessment techniques and tools to fill in the gaps until a more complete, robust set of Web service specific security testing tools emerges.

Tools for security testing of groups of Web services interacting across SOAs do not yet exist, nor do tools for testing security of Web services that are dynamically defined at runtime (e.g., through orchestration or choreography).

Web services provide interoperability among a variety of development platforms and operating systems, giving organizations flexibility when implementing them. To maximize this flexibility, it is important to understand the security benefits provided by some of the most widely used Web service development languages and what tools are available in those languages to aid in the development of Web services. Web service toolkits can prove to be essential to developing secure Web services, particularly if they are WS-I Basic Profile and WS-I Basic Security Profile compliant—allowing for interoperability with little or no change to the code generated by the toolkit. In addition, a robust XML parser is essential for developing Web services to prevent attacks designed to compromise the parser.

There are several languages commonly used to develop Web services: Java, C#, VB.NET, C, and C++. Java, C#, and VB.NET rely on managed code frameworks to provide many of the support functions necessary to implement Web services. C and C++ can provide performance improvements over their managed code counterparts and may be the only option when Web service-enabling a legacy application.

Regardless of what language is being used, the use of secure software development techniques is essential to preventing a number of vulnerabilities from being introduced into the Web service. To minimize the number of vulnerabilities in a Web service, testing tools and techniques can be used to perform penetration testing, functionality testing, source code review, and other tests. Through the use of WS-I compliant toolkits, secure software development practices, and security testing, it is possible to implement secure Web services that will withstand a wide variety of attacks.

The following are common attacks targeting vulnerabilities often found in Web services. With exceptions noted in brackets, Web services are subject to these attacks.

A.1 Reconnaissance Attacks

Reconnaissance attacks have the objective of collecting information about an application and its execution environment to better target other types of attacks at that application. There are no standards for preventing reconnaissance attacks. UDDI v3.0.2 provides some protection against reconnaissance attacks by requiring identification, authentication and authorization of entities prior to granting access to the registry. Other discovery standards, such as WSDL, can be accessed by any entity and the information may be used in reconnaissance attacks. It is important to ensure that only authorized entities can gain access to discovery information, to Web service interfaces, and to Web service messages in transit.

A.1.1 Code Templates

The use of code templates and comments in code can provide information about the backend systems or the development environment of the Web application. Specifically, the use of template code can prove to be dangerous. This code can be obtained from many sources and can contain bugs that are easily identified in the source code. This information can be used to exploit a specific vulnerability or narrow the focus of vulnerability scans performed on the system.

A.1.2 Forceful Browsing Attack

Forceful browsing attacks attempt to detect Web services that are not explicitly publicized. An example of forceful browsing is an intruder making repeated requests to the Web service with the URL patterns of typical Web application components such as common gateway interface (CGI) programs. Depending on error messages received, this technique can be used to gain information about the unpublicized Web service.

A.1.3 Directory Traversal Attack

A directory traversal attack is closely related to a forceful browsing attack. Directory traversal occurs when an attacker tries to access restricted files used by a Web service. Usually, the requested files reside outside of the Web service host’s normal file system directory, but they can also include resources within the service’s host server that are restricted from being accessed by the attacker. Directory traversal attacks against Web services can be used to access the host server’s password files or to access executables on the server to execute arbitrary commands.

A.1.4 WSDL Scanning