2 Overview of OpenSSO Security Token Service

Oracle OpenSSO Security Token Service (OpenSSO STS) provides a secure way to handle identity propagation that is controllable by policy. As a trusted authority service, OpenSSO STS issues and validates security tokens. As a web services security provider, OpenSSO STS secures communication between web service clients and the OpenSSO STS server itself. This chapter provides a high-level overview of how OpenSSO STS works, and what it can do for your enterprise.

The following topics are contained in this chapter:

About OpenSSO STS
Common Uses for OpenSSO STS
Single-Realm Administration Console

2.1 About OpenSSO STS

In most enterprises, users are assigned to a single authentication mechanism which is mapped to a security role. But when a business requires applications and services that are not tied to a particular credential type or to a particular set of roles, then the claims-based security model work best.

OpenSSO STS is a service that assigns a claim, or security token, to an authenticated user. A security token is a more granular artifact than a role. Based on the assigned security token, the user can then be authorized to use a protected web application. In this way, Open SSO STS decouples applications and services from roles, and enables you to change the name and meaning of roles without affecting the system.

You can configure OpenSSO STS to act as a security token service, and as a web service security provider. When you configure OpenSSO STS as a security token service, applications can delegate authentication, user identity mapping, and user identity management to the OpenSSO STS authority.

When configured as a web service security provider, OpenSSO STS protects the security token service itself from unauthorized use or security breach. When you configure OpenSSO STS to act as a web service security provider, you must configure both the web service client and the web service provider.

2.1.1 The OpenSSO Security Token Service

The OpenSSO Security Token Service was developed from the WS-Trust protocol. The WS-Trust protocol defines extensions to the WS-Security specification for issuing and exchanging security tokens and establishing and accessing the presence of trust relationships. The OpenSSO Security Token Service is hosted as a servlet endpoint and coordinates security-based interactions between a Web Service Client and a Web Service Provider. The OpenSSO Security Token Service is a stand-alone service that issues SAML tokens with inbound tokens that are compliant with the WS-I Basic Security Profile.

2.1.2 OpenSSO STS as a Web Service Security Provider

OpenSSO STS provides web service security support for client applications that are based on the Java API for XML Web Services (JAX-WS) or SOAP with Attachments API for Java (SAAJ). For JAX-WS based clients, web services security can be enforced at either the web or J2EE container level using container-provided security authentication and authorization plug-ins, or using JAX-WS Handlers. Handlers are interceptors that can be easily plugged into the Java API for XML-Based Web Services (JAX-WS) 2.0 runtime environment to do additional processing of inbound and outbound messages.

2.1.3 OpenSSO STS Agent Profiles

OpenSSO STS uses agent profiles to store configuration data for securing token requests sent to the Security Token Service. Agent profiles include web service client, OpenSSO STS client, and web service provider profiles.

OpenSSO STS client and web service client profiles can be used by client applications to secure communication between a client and OpenSSO STS or other web service provider. A web service provider configuration profile is used by both OpenSSO STS as well as a stand-alone web service provider.

2.2 Common Uses for OpenSSO STS

You can deploy OpenSSO STS as a stand-alone token security service, or as a component in a web service security solution.

2.2.1 Stand-Alone Security Token Service

OpenSSO STS leverages WS-Trust to manage token exchange between a web service client and a web service provider. The WS-Trust specification provides a standards-based way to send security token requests to any security token service. WS-Trust can be used to manage token transformation when crossing the various security boundaries of the information system. The following figure illustrates how OpenSSO STS facilitates an interaction between a web service client and web service provider through brokered authentication.

Figure 2-1 Security Token Service Process Flow

Description of "Figure 2-1 Security Token Service Process Flow"

2.2.2 Web Services Security Provider

OpenSSO STS can be deployed to work with other Oracle components to provide comprehensive web services security. In web service deployments that require WS-Security, Oracle Access Manager is often used to address the authentication requirements in the environment. Additionally, Oracle Web Services Manager can provide a standards-compliant solution that enforces authorization and ensures confidentiality, privacy, and data integrity. The following example demonstrates how OpenSSO STS is used for identity propagation from a web service client to communicate with a web service provider.

An end-user logs in to an application named StockClient to configure a list of company stocks, and to periodically view current stock prices. In this example, StockClient is the web service client that communicates with the web service provider named StockService. OpenSSO STS propagates a user identity from the web service client. SOAP Messages are used to transfer the security tokens and to communicate between web services client and web service provider.

Figure 2-2 OpenSSO STS as a Web Service Security Provider

Description of "Figure 2-2 OpenSSO STS as a Web Service Security Provider"

Access Manager handles the initial user authentication though a browser redirect by the Access Manager policy agent. Both StockClient and StockService are protected by the Web Services Manager policy agent that intercepts the request at the Web Service Provider, and the response at the Web Service Client. Web Services Manager then executes policies attached to each request and response in the transaction. Web Services Manager policy agents look up policy definition details in the Web Service Manager Policy Manager, and caches the policies to increase performance. Any changes to policy are dynamically updated by the Policy Manager. The Policy Manager propagates the changes to the policy agent which refreshes the policy cache and applies the changed policy immediately to the next request received.

If WS-Security is not a requirement, then Web Services Manager can be replaced with standard WS-Trust clients such as a WebLogic Server client. The WebLogic Server client communicates with OpenSTS on the web service client side, and uses a J2EE agent on the web service provider side.

2.3 Single-Realm Administration Console

After OpenSSO STS is deployed and configured, a single top-level realm is created. A realm is the administrative unit for OpenSSO STS. The Top Level Realm contains all configuration data for the OpenSSO STS instance except for bootstrapping information configured during installation. The Top Level Realm cannot contain subrealms. Information defined in the Top Level Realm includes:

The location of one or more identity repositories containing users to whom the remaining configuration information applies.
An authentication process that defines, among other information, the location of an authentication repository and the type of authentication required.
Configuration data for the OpenSSO STS service itself. This includes configuration data for the OpenSSO STS authentication service, host server, global settings, and server and site management.