test

Sun OpenSSO Enterprise 8.0 Technical Overview

About Web Services Security

A web service exposes some type of functionality using a platform-independent interface. Enterprises use platform-independent interfaces as a mechanism for allowing their applications to cross network boundaries and communicate with those of their partners, customers and suppliers. Web services are accessed by sending a request to one of the service's defined endpoints but the built-in openness of the web services technologies creates security risks. The following security requirements have been identified and must be supported to insure that the communications between a web service provider (WSP) and a web service client (WSC) are not compromised.

Initially, securing web services communications was addressed on the transport level, relying on securing the HTTP transmissions themselves using Secure Sockets Layer (SSL). This is not adequate though when access to an application is requested through an intermediary. The solution to this is to encrypt the entire request using message level security before it leaves the WSC. In message level security, authentication and authorization information in the form of a token is contained within the SOAP header, allowing the request or response to securely pass through multiple intermediaries before reaching its intended receiver. Figure 14–1 depicts message level security.

Figure 14–1 Message Level Security

Illustration of security context in message level security

Note –

Additionally, policy enforcement points are distributed throughout the environment and access to resources and services is mainly over HTTP.

The OpenSSO Enterprise Web Services Security functionality can be used in a variety of platforms and containers for different purposes. These can range from providing single sign-on and federation support for web applications to securing web applications using security agents deployed on the appropriate web container. Here are the web services security functions that OpenSSO Enterprise provides.

Basically, the JCP, W3C, and OASIS are developing specifications related to web services security. WS-I creates profiles that recommend what to implement from various specifications and provides direction on how to implement the specifications. The Liberty Alliance Project provides a framework for building interoperable identity services, using specifications such as WS-Security (OASIS), SOAP, Security Assertions Markup Language SAML (OASIS) and XML (W3C). The following sections briefly discuss the specifications and profiles being developed by each organization.

There are a number of web services security specifications, guidelines, and tools that have been implemented to develop these Web Services Security features for OpenSSO Enterprise. The following sections have more general information on these specifications.

Web Services Interoperability Technology

Web Services Interoperability Technology (WSIT) is an open source implementation of many of the web services specifications (commonly referred to as WS-*). The project was started by Sun Microsystems, and consists of Java API that allow developers to create web service clients and services that enables operations between the Java platform and clients and servers developed with the WS-* specifications. WSIT provides implementation of the following specifications for interoperability with .NET 3.0.

Note –

Web service specifications are referred to collectively as WS-* although there is neither a single managed set of specifications that this consistently refers to nor one recognized body that owns all the specifications. WS-* is a general nod to the fact that many specifications use WS as their prefix.

Sun is working closely with Microsoft to ensure interoperability of web services enterprise technologies such as message optimization, reliable messaging, and security. The initial release of the Web Services Interoperability Technologies (WSIT) is a product of this joint effort. WSIT is an implementation of a number of open web services specifications to support enterprise features such as message optimization, reliable messaging, security, bootstrapping and configuration. More information can be found in this WSIT tutorial on java.sun.com.

WS-Security Specification

The WS-Security specification is now developed by the Organization for Advancement of Structured Information Standards (OASIS) after being submitted to the standards body by IBM, Microsoft, and VeriSign in 2002. The specification defines how to sign a SOAP message and describes enhancements that provide message integrity, message confidentiality, and message authentication. It also defines:

The WS-Security specification is designed to be used together with other WS-* specifications to provide tools for secure and reliable web services transactions. For example, WS-Policy does not provide a solution for negotiating web services in and of itself; it is used in conjunction with other specifications to accommodate a wide variety of policy exchange models. WS-Trust, on the other hand, uses the secure messaging mechanisms of WS-Security to define extensions for security token exchange within different trust domains. For more information, see the Web Services Security page on the OASIS web site.

WS-Trust Specification

Web Services Trust Language (WS-Trust) uses the secure messaging mechanisms of WS-Security to define additional extensions for security token exchange and to enable the issuance and dissemination of credentials within different trust domains. WS-Trust is used to develop the Security Token Service. For more information, see Security Token Service.

Liberty Alliance Project Specifications

The Liberty Alliance Project establishes open technical specifications that support a broad range of web services, driving the specifications for services such as Personal Profile Service and the Employee Profile Service. In order to build these identity web services, the Liberty Alliance Project provides a framework for identity federation and a framework for adjunct web services such as a registration service and a discovery service. For more general information on the Liberty Alliance Project, see Using the Liberty ID-FF and the Liberty Alliance Project specifications.

JSR-196 Specification

The Java Community Process (JCP) primarily guides the development and approval of Java technical specifications, one of which is the Java Specification Request (JSR) 196. JSR 196 is a draft of the Java Authentication Service Provider Interface for Containers that defines a standard service provider interface (SPI) with which a message level security agent can be developed for Java EE containers on either the client side or the server side.

The JSR–196 SPI is structured so that the security processes can be delegated to an agent at any of four interaction points (that represent the methods of the corresponding ClientAuthModule and ServerAuthModule SPI). These point are illustrated in Figure 14–2.

Figure 14–2 Four Security Process Points

The four points in the interaction between a web service client and web service provider where security processes can be added.

When a WSC and WSP are both deployed in a Java EE web container protected by JSR–196 security agents, the initial request from the WSC is intercepted by the agent on the client side which then queries a trusted authority (for example, the Discovery Service) to retrieve the necessary authorization credentials to secure to the request. The secured request is then passed to the WSP. The agent on the provider side receives the request to validate the authorization credentials. If validation is successful, the request is exposed to the web service and a response is created using the sender's credentials and the application specific request. The response is then intercepted by the agent on the provider side to secure and return it to the WSC. Upon receiving the response, the agent on the client side validates it and dispatches it to the client browser. The JSR 196 draft specification is available at http://www.jcp.org/en/jsr/detail?id=196.