SP Brokering Example

Let us assume that two companies Digital Airlines and ACME are business partners. There are certain applications that users of both Digital Airlines and ACME require to access.

With SP Brokering, users in Digital Airlines are provided with an intersite transfer URL that allows users to authenticate at Digital Airlines, set the assertion at ACME, and give access to the target application. With this approach, users do not need to choose from different authentication cards.

The following diagram depicts the SP Brokering workflow:

Workflow:

  1. A user is authenticated at Digital Airlines identity provider. The user clicks Broker URL. Digital Airlines checks if this user is authenticated. If not, it asks for user credentials and authenticates the user.

  2. Digital Airlines identity provider processes an intersite URL and creates an assertion for SP Broker (Access Manager Identity Server).

  3. SP Broker receives the assertion and validates that this assertion is received from a trusted identity provider.

  4. SP Broker checks if the trusted identity provider and the service provider (available in the target URL) belong to the same group. SP Broker denies the request if both do not belong to same group.

  5. SP Broker sends a request to Digital Airlines identity provider to resolve the artifact.

  6. SP Broker receives the SAML assertion from Digital Airlines identity provider and caches attributes/roles received. SP Broker applies any Role policies that have been enabled.

  7. SP Broker performs intersite transfer. In the processing of intersite transfer, SP Broker checks if this user was a result of SP Brokering (step 4 earlier). SP Broker enforces the SP Brokering rules check: if any of the rules result in deny, an error page is displayed.

  8. SP Broker creates an assertion for ACME.

  9. ACME sends a request to SP Broker to resolve the artifact.

  10. ACME receives the SAML assertion from the SP Broker along with roles/attributes.

  11. ACME sends a redirect to the final target URL. (Note: Redirect happens from ACME’s ESP to ACME’s identity provider where the user is already authenticated.)

  12. The user accesses the target application.