search
About CoherentAPI referenceSupportYouTube

Federation

Spark implements Service Provider Initiated authentication using the Identity Broker Pattern. In Service Provider Initiated authentication, the user first attempts to access the Service Provider (Spark), which then redirects the user to the Identity Broker (Keycloak) for authentication, rather than the process being initiated directly by the Identity Provider.

The Identity Broker Pattern, which is a part of federation, involves an intermediary (the Identity Broker) that sits between an Identity Provider (IDP) and a Service Provider (SP). Here’s how this pattern works with the components involved.

hashtag
Components

hashtag
Identity Provider (IDP)

The Identity Provider is responsible for authenticating users. It stores user identities, credentials, and other relevant attributes. When a user attempts to log in, the Identity Provider handles the authentication process.

Spark supports integration to various Identity Providers including Microsoft Entra IDarrow-up-right, Oktaarrow-up-right, PingOnearrow-up-right. Documentation on how to integrate Spark with these IDPs are in the section Single Sign-On.

hashtag
Identity Broker: Keycloak

Keycloakarrow-up-right acts as the intermediary between the Identity Provider and the Service Provider. It brokers authentication requests by receiving them from the Service Provider, forwarding them to the Identity Provider, and then processing the response. Keycloak can also manage additional identity services, such as role/attribute mapping or session management.

hashtag
Service Provider (SP): Spark

The Service Provider is the application or service that requires authentication to grant users access. It relies on Keycloak to manage the authentication process. The SP trusts Keycloak to verify user identities and provide the necessary user information (e.g. groups, permissions) after authentication.

hashtag
Authentication flow

This flow demonstrates how Spark's IDM architecture operates using the Identity Broker Pattern, where Spark initiates the authentication process, Keycloak brokers the requests to the Identity Provider, and Spark grants access based on the tokens provided. This ensures secure and streamlined federation.

  1. The user accesses Spark. Since the application is protected, the user must be authenticated.

  2. Spark, recognizing that the user is not authenticated, redirects the user's browser to Keycloak, the Identity Broker. This redirection initiates the authentication process using the Authorization Code Flow with PKCE.

  3. Keycloak forwards the authentication request to the configured Identity Provider. The user is prompted to authenticate with the Identity Provider. This typically involves entering credentials (e.g., username and password).

  4. Upon successful authentication, the Identity Provider sends a response back to Keycloak.

    • If OpenID Connect (OIDC) is used: The response will include an ID token and possibly an Access token.

    • If SAML is used: The response will include a SAML assertion.

  5. Keycloak processes the authentication response and issues its own ID token, Access token, and Refresh token. These tokens are stored in the user's browser local storage.

  6. Keycloak then redirects the user back to Spark with the necessary authentication information. Spark receives the tokens from Keycloak via the browser and verifies them. Once the tokens are validated, the application grants access to the user.

Last updated