Sun OpenSSO Enterprise 8.0 Technical Overview

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.


Note –

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

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.