Sun OpenSSO Enterprise 8.0 Deployment Planning Guide

Securing Web Services

Your enterprise solution must include a means for securing your web services from unauthorized use. OpenSSO Enterprise supports web services security using the Identity Web Services Framework (ID-WSF), part of the Liberty Specification. OpenSSO Enterprise also supports web services security using the Secure Token Service, which is defined in the WS-* Specification.

Web services are self-contained, modular applications that can be described, published, located, and invoked over a network. Web services perform encapsulated business functions, ranging from a simple request-reply to complete business process interactions. Web services based on the following allow data and applications to interact without manual intervention:

A typical Web services application consists of a service consumer, a service provider, and optionally a registry for storing the Web services definitions. Web services are accessible over standard Internet protocols that are independent of platforms and programming languages. 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.

A number of technologies such as Remote Procedure Call (RPC) Common Object Requesting Broker Architecture (CORBA), Microsoft Distributed Component Object Model (DCOM) have been developed for application integration. However, the web services technology based on XML, SOAP and HTTP(S) has been accepted as an industry standard and has seen wide industry adoption. Interoperability has been a key reason for the success of web services because it is based on open standards. Enhancements to web services should preserve the interoperability and should be based on open standards.

Many of the features that make Web services attractive, including greater accessibility of data, dynamic application-to-application connections, and relative autonomy or lack of human intervention are at odds with traditional security models and controls. Network security technologies such as firewalls are inadequate to protect SOAs for the following reasons:

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. According to WS-I, the top threats facing Web services are:

The importance of these threats varies depending upon your company's needs and purpose. For most companies, internal messages must be kept confidential and loss of confidentiality is a primary concern. However, many companies offer web services to the public at large. For some services, identity authentication is not a significant concern. For example, a web service provider that serves 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.

Web Services Security Industry Specifications

OpenSSO Enterprise is based upon the following industry-recognized specifications:

Security Infrastructure Requirements

In a simple web service transaction, a request is sent from the Web Service Client to a Web Service Provider through intermediaries such as load balancers and firewalls. Similarly, the response from the Web Service Provider to the Web Service Client is also sent through the same intermediaries. In order to protect the web service request, application-level end-to-end security must be enabled in addition to transport-level security.

The following diagram shows a simple web service call between the Web Service Client and Web Service Provider.

Figure 1–1 Simple Web Service Call

End-to-end security from Web Service Client to
Web Service Provider.

In order to secure the message, the Web Service Client must determine which security mechanisms are required by the Web Service Provider. One solution is to pre-configure the Web Service Client with the security requirements for Web Service Provider. Although simple, this approach would not scale and could lead to other misconfigured Web Service Clients.

An alternative architecture for web service security is an architecture based on Security Token Service (STS). The Liberty Alliance Discovery Service and WS-Trust are examples. A security token service that coordinates security-based interactions between a Web Service Client and Web Service Provider.

First, the Web Service Provider registers its acceptable security mechanisms with the security token service. Then, before making a call to the Web Service Provider, the Web Service Client connects with the Security Token Service to determine the required security mechanisms. The Web Service Client might also obtain the security tokens required by the Web Service Provider. Before validating the incoming SOAP request, Web Service Provider checks with the security token service to determine its security mechanisms. The following figure illustrates interactions between the Web Service Client, Web Service Provider, and Security Token Service.

Figure 1–2 Web Service Call with Security Token Service Enabled

Web Service Client and Web Service Provider have
direct communication with Security Token Service.

Although this security model requires the security token service, it helps in coordinating security mechanisms between the Web Service Client and Web Service Provider. Additionally, it enables runtime decisions for both Web Service Client and Web Service Provider. This makes the configuration dynamic and more responsive than a static configuration. However it does introduce the extra overhead of the Web Service Client and the Web Service Provider to communicating with the security token service. It also introduces the complexities of notification mechanisms when the Web Service Provider changes its security mechanisms. Your decision to either the static or dynamic configuration of Web Service Clients must be based on your deployment environment. The architecture proposed in this document addresses both the scenarios.

Security Token Service

The purpose of the security token service is to orchestrate secure communications between the Web Service Client and Web Service Provider with minimal performance penalties. The following are required for a security token service:

Liberty Alliance's Discovery Service and WS-Trust are the emerging standards specifications, and either one can play the role of the security token service. Both the specifications define the wire protocols for the Web Service Client to query and obtain the security tokens to communicate with the Web Service Provider. One important difference exists between the two. The Liberty Alliance Discovery Service provides the interfaces for the Web Service Provider to manage its entry in the secure token service. In WS-Trust specification, the WS-Trust entry is managed by the Web Service Provider itself. The WS-Trust entry is provided to the Web Service Client through a WS-Trust Meta-Data Exchange (MEX) Protocol.

Web Service Client

The Web Service Client which makes the web service call provides support for securing the outgoing communication, and also validates the incoming response for Web Service Provider. The Web Service Client security infrastructure requires the following:

Two kinds of interfaces are needed at the Web Service Client. One interface is needed for configuration and administration. One interface is used at run time for securing requests and validating responses.

Web Service Provider

The Web Service Provider provides support for validating the incoming request, and also secures the outgoing responses. The Web Service Provider security infrastructure requires the following:

Similar to interfaces needed by Web Service Client, the Web Service Provider also requires two kinds of interfaces. One interface is needed for configuration, and another interface is needed for validating requests and securing responses. Supporting a Web Service Client and Web Service Provider security infrastructure should be accomplished in either a pluggable manner such that it does not require reconfiguring the existing web services framework. Or it can be accomplished programmatically by calling well-defined interfaces to secure requests and validate responses. Additionally, the infrastructure should enable customers to easily build and configure interoperable solutions using heterogeneous systems.