Red Hat DocumentationFuse ESBToggle FramesPrintFeedback

Overview of the Demonstration

Overview

This section describes how to set up and run a WS-Trust single sign-on (SSO) demonstration. The demonstration is based on the following Apache CXF samples;

samples/sts_issue_operation

Implements a lightweight STS, supporting only the Issue operation.

samples/wsdl_first_https

A basic Web service client/server sample, with TLS enabled on the client/server connection.

The instructions in this section explain how to modify these two samples, in order to obtain a demonstration of WS-Trust single sign-on. Figure 12 gives an overview of the WS-Trust single sign-on scenario implemented by this demonstration.

Figure 11. WS-Trust Single Sign-On Scenario

WS-Trust Single Sign-On Scenario

Steps for single sign-on

The WS-Trust single sign-on scenario shown in Figure 12 proceeds as follows:

  1. Before invoking an operation on the server for the first time, the client initiates SSO login by contacting the Issue binding on the STS.

  2. The client presents its own X.509 certificate, wibble, during the TLS handshake. On the STS side of the connection, the JAX-WS endpoint verifies the client certificate using the CA certificate, wibble_ca, and on the client side, the client verifies the STS certificate using a stored copy of the STS certificate, stsstore.jks.

  3. The STS creates a SAML 2.0 token and the token issuer private key is used to sign the SAML token (where the signature is shown as # in the figure). This enables relying parties (WS servers) to verify the integrity of the SAML token.

  4. The STS replies to the client, sending back the signed SAML token.

  5. The client initiates a connection to the server, in order to invoke an operation.

  6. During the TLS handshake, the client presents its own X.509 certificate, wibble. On the server side of the connection, the JAX-WS endpoint verifies the client certificate using the CA certificate, wibble_ca, and on the client side, the client verifies the server certificate also using the CA certificate, wibble_ca.

    After the connection is established, the client sends an invocation request to the server, which includes the SAML token embedded in a SOAP header.

  7. The server tests the integrity of the received SAML token using the token issuer public key (which complements the token issuer private key used by the STS). If this test is successful, it proves that the SAML token has not been modified or corrupted since it was issued by the STS.

Demonstration parts

To configure and run the WS-Trust single sign-on demonstration, follow the instructions in these demonstration parts:

Comments powered by Disqus