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

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

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:

• Interfaces that enable the Web Service Provider to manage its entry, or resource offering. This includes interfaces that enable the Web Service Provider to store supported security mechanisms, and optionally the service end points.

• Interfaces that enable the Web Service Client to query for security mechanisms supported by a Web Service Provider.

• Interfaces that enable a Web Service Client to obtain security tokens for communicating with the Web Service Provider.

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:

• Configurations to determine STS and credentials to authenticate and obtain WSP resource offerings.

  Optionally there should be provision to statically configure the resource offering locally

• Interfaces to obtain WSP resource offering either from STS or optionally from the local configuration

• Interfaces to secure the request. This could be accomplished by calling the STS for the security token or should be locally generated. The security token generated could be either that of the WSC itself or it could be that of the authenticated entity (impersonalization)

• In addition to adding the security token it should be possible to add additional attributes of the identity, for example roles and memberships

• Interface to validate the response received from WSP.

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:

• Configuration for its supported security mechanisms. This configuration can be optionally stored in STS, thereby providing dynamic discovery for WSCs. This is supported by Liberty Alliance's Discovery Service, but it in the case of WS-Trust this would have to locally configured for WS-Trust MEX calls.

• Interfaces to authenticate the incoming request from the Web Service Client

• After authentication, if configured, the Web Service Provider should also authorize the request for the web service operation by calling the policy component.

• Interfaces to secure the response back to the Web Service Client

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.