• The WSC requests that a security token service (STS) issue a SAML token to convey information between the WSC and the WSP.
  • The WSP sends the STS a request to validate the incoming token. Optionally, the WSP can request that the STS issue a local token for the service provider (SP) domain.

When issuing and validating security tokens, PingFederate enforces security policies, defined by administrators, generating the token types that are required for a web service request to pass between two security domains (whether these domains are within the same organization or in separate organizations).

Token exchange (example)
Diagram illustrating a token exchange, using PingFederate to obtain a SAML assertion. The SAML assertion is used in the WSS-secured web service call.

Processing steps

  1. A user requests content from an application.
  2. The application acts as a WSC to respond to the user's request. The application calls PingFederate, passing the existing user security token to exchange it for the appropriate SAML assertion.
  3. PingFederate verifies the existing security token, creates a new SAML assertion representing the user, and returns it to the requesting application.
  4. The application sends a web service request to the WSP, including the SAML assertion in a WS-Security header.
  5. The WSP retrieves the SAML assertion from the WS-Security header in the incoming request and sends a message to its own deployment of PingFederate to determine if the assertion is valid.
  6. PingFederate validates the SAML assertion, creates a new security token for the local domain, and returns the new token to the WSP.
  7. The WSP responds to the request according to its policy for the user.
  8. The web application returns an HTML page to the user.
    Note:

    This example shows PingFederate deployed in both the WSC and WSP sides of the interaction. However, other deployment options are also supported.