LibraryToggle FramesPrintFeedback

The WS-Trust single sign-on scenario shown in Figure 8.6 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.

Comments powered by Disqus
loading table of contents...