Web Services Security in OpenSSO Enterprise

OpenSSO Enterprise can provide web services security for client applications that built using the SOAP with Attachments API for Java (SAAJ) and Java API for XML Web Services (JAX-WS). For SAAJ applications, the OpenSSO Enterprise Client SDK can be used to explicitly secure and validate the outbound and inbound messages between the WSC and WSP. For JAX-WS applications, web services security can be enforced at the web container level with container-provided security plug-ins or handlers.

The JSR–196 specification is a security plug-in SPI supported by the Sun Java System Application Server. Handlers are interceptors that can plugged into the JAX-WS 2.0 runtime environment for additional processing of inbound and outbound messages.

The following sections have more information.

• Web Services Security Internal Architecture

• Web Services Security Deployment Architecture

Web Services Security Internal Architecture

The architectural strategy behind the Web Services Security framework is to model security agents on authentication and authorization SPI provided by the web container and to use a WSIT infrastructure for WS-Trust, WS-Policy and WS-I BSP security token implementations. Security agents secure web service requests and validate web service responses by inserting (or extracting) security tokens into (or out of) SOAP messages at the WSC and the WSP. This abstracts security from the application and allows customers to standardize security across multiple containers. Figure 14–3 illustrates this.

Figure 14–3 Architecture of Web Services Security Components

The Web Services Security framework supports the following tokens.

• Tokens that can be authenticated:

  1. UserName

  2. X509

  3. SAML 1.1

  4. SAML 2.0

  5. Kerberos

• Tokens that can be issued:

  • UserName (generated with the Security Token Service or locally at the WSC)

  • X509 (generated with the Security Token Service or locally at the WSC)

  • SAML 1.1 (generated with the Security Token Service or locally at the WSC)

  • SAML 2.0 (generated with the Security Token Service or locally at the WSC)

  • Kerberos (generated locally at the WSC)

In general, securing web services involves establishing trust between a WSC and a WSP. Towards this end, OpenSSO Enterprise provides security agents to verify (and extract data from) security tokens on incoming requests and to add security information (tokens and signatures) to outgoing responses. It also provides a Security Token Service to handle security tokens, and a number of Java interfaces. The following sections contain more information on these components.

• Security Token Service

• Security Agents

• Web Services Security and Security Token Service Interfaces

Web Services Security Deployment Architecture

OpenSSO Enterprise can be configured for use as a Security Token Service, as a web services security provider, and as both. Messages used to transfer security tokens between communicating web services clients and providers are exchanged with SOAP. The following use case and deployment architecture is not intended to cover all potential scenarios.

A company employee has a user account in the A identity system and wants to access an internal calendar application which invokes a remote calendar web service to provide it's features. Sufficient identity and attribute information on behalf of the user must be supplied by the internal calendar application to the remote calendar web service in a secure manner. This figure illustrates how this use case could be configured. A detailed process flow follows.

The application and web service are in the same domain and both are deployed using Sun Java System Application Server and a security agent.

Figure 14–4 Web Service Security Deployment Architecture

1. The authenticated employee uses the A Portal to invoke the internal calendar application and, at some point, accesses a link requiring it to make a web service call to the remote calendar web service on behalf of the authenticated user.

   ---

   Note –

   The internal calendar application is acting as a WSC.

   ---

2. The security agent protecting the internal calendar application intercepts the outbound SOAP message, connects to a token authority (in this case, the Security Token Service), determines the security mechanisms of the WSP, obtains the appropriate security token(s), and secures the request by inserting the tokens (in the form of a SAML assertion) into the SOAP request headers.

3. The security agent forwards the secured SOAP message to the remote calendar web service acting as the WSP.

4. The security agent protecting the remote calendar web service intercepts the inbound SOAP message.

5. The security agent protecting the remote calendar web service retrieves and validates the security information and, upon successful validation, forwards the request to the remote calendar web service.

6. The calendar web service sends back a response.

7. The security agent protecting the remote calendar web service intercepts the outbound SOAP message and digitally signs the request with its private key.

8. The security agent protecting the internal calendar application intercepts the inbound signed SOAP message, validates the signature, and, upon successful validation, forwards the request to the application.

9. The calendar application consumes the results and presents the employee with the appropriate response.

For identity-based web services specifically (a calendar service for example), the WSP would have to trust the WSC to authenticate the user, or the WSC would have to include the user's credentials as part of the web service request. The distinguishing factor is that identity-based web services authenticate both the WSC and the user's identity. The user must be authenticated so that the WSC can send the user's token to the WSP in a SOAP security header.