Federating an Identify Provider from an IAM

In today’s interconnected digital ecosystem, identity and access management (IAM) solutions often face the need to delegate authentication tasks to external identity providers (IdPs). This process, known as federating an identity provider, enables seamless integration across platforms, organizations, and even customer-facing services.

Below, we’ll explore two distinct cases of federation, considering both internal and customer IAM use cases. Each scenario has unique drivers and technical considerations that influence its implementation.

Use Case: Internal IAM Federation

An organization uses an internal IAM solution to authenticate its users but needs to federate authentication to another trusted IdP. This commonly arises when collaborating with partner organizations or integrating with enterprise-wide identity solutions.

Here are some common use cases for internal IAM federation:

• Cross-Company Collaboration: Federation with an IdP from a partner company for secure access to shared resources.
• Centralized Identity Governance: A large enterprise consolidates authentication for multiple business units using different IAM systems under a unified corporate IdP.

Key Considerations

When federating an IdP from an internal IAM solution, several factors must be considered to ensure a seamless and secure integration:

• Trust Relationship: Establishing a trust mechanism between the internal IAM and the external IdP. This often involves signing OIDC contracts, exchanging metadata, and using secure transport layers.
• Protocol Alignment: Ensuring both the internal IAM and the external IdP support the same OIDC specifications and features, such as claims mappings, token lifetimes, and scopes.
• User Synchronization: Deciding whether user attributes will be synchronized in real-time or fetched dynamically using claims from the federated IdP. Security like ensuring strict compliance with access policies.

Use Case: Consumer IAM (CIAM) Federation

A business offering customer-facing services uses its IAM solution but wants to simplify login processes by allowing users to authenticate with their preferred external IdPs, such as social logins (Google, Facebook, Apple) or state-backed IdPs like FranceConnect in France.

Here are some common use cases for CIAM federation:

• Social Logins for Convenience: Allowing customers to log in using accounts they already have (e.g., Google, Facebook).
• State or Federated Identities: Enabling login via government-backed IdPs for services requiring legal identity verification, such as healthcare or e-government services.

Key Considerations

When federating an IdP from an IAM solution, several factors must be considered to ensure a seamless and secure integration:

• User Onboarding: Ensuring a seamless onboarding experience by mapping user attributes from the external IdP to the customer IAM.
• Branding and Trust: Maintaining a consistent brand experience while integrating third-party authentication.
• Privacy: Balancing ease of use with customer privacy, ensuring only essential data is shared and stored.

Federation Protocols: OIDC, SAML, and Beyond

When implementing federation between IAM systems and external IdPs, selecting the right standard protocol is critical to ensure compatibility, security, and performance. The two most commonly used federation protocols are OpenID Connect (OIDC) and Security Assertion Markup Language (SAML 2.0). Both offer robust frameworks for federated identity but differ in their approach, use cases, and technical foundations.

Protocol Interoperability

In some cases, organizations may need to bridge the gap between OIDC and SAML. For example, an internal IAM system supporting SAML may need to federate with a modern IdP using OIDC. Middleware solutions and identity brokers (e.g., Okta, Keycloak, PingFederate or Azure AD) can facilitate protocol translation, allowing systems to communicate seamlessly despite protocol differences.

Implementing Federation Using OpenID Connect

Federating an IAM solution with an external Identity Provider (IdP) using OpenID Connect (OIDC) involves integrating your IAM system with the OIDC flow to delegate authentication and obtain user information securely. This section provides an overview of the steps and best practices for implementing OIDC federation.

OIDC Flow Overview

Before implementation, it’s crucial to understand how the OIDC protocol works in this case. Federation typically uses the Authorization Code Flow (with PKCE extension), which ensures secure interaction between your IAM system (acting as a client) and the external IdP. The flow involves the following steps:

1. Authorization Request: The IAM system redirects the user to the external IdP’s authorization endpoint, passing parameters such as client ID, redirect URI, and requested scopes.
2. Authorization Response: The IdP authenticates the user and redirects back to the IAM system’s redirect URI with an authorization code.
3. Token Exchange: The IAM system exchanges the authorization code for tokens (ID token, access token) by calling the IdP’s token endpoint.
4. User Information Retrieval: The IAM system uses the ID Token when exists or uses Access Token to call the IdP’s userinfo endpoint for additional user claims.
5. Session Establishment: The IAM system establishes a session and provides access to the application.

First Login Flow

During the first login, the user is redirected to the external IdP for authentication. The IdP may prompt the user consent for sharing information as it is the first time the user logs in.

After successful authentication, the IAM receives Access Token and most of the time ID Token. As it is the first login, the IAM system may create a new user account. IAM system will store at least the user identifier (sub) to link the external user to the internal user during subsequent logins.

Subsequent Logins Flow

For subsequent logins, the flow is the same except that the user will not be prompted for consent again as the user has already granted it during the first login. In some cases, if the scopes changes for instance, the user may be prompted for consent again. When IAM receives the Access Token and ID Token, it will use the user identifier (sub) to link the external user to the internal user.

In order to keep the data up-to-date, the IAM system may keep mapping the user claims from the external IdP to the internal user account during each login.

What about Account Linking?

Account linking is the process of associating an external user account (from the IdP) with an internal user account in the IAM system based on user attributes (e.g., email, phone number). This process can help maintain a consistent user experience and ensure data integrity across systems. If you already have an account with the same email address but you did not remember and this time you want to use Google to log in for instance, this can avoid creating a new account.

However, account linking can add security challenges, such as ensuring that the user is the legitimate owner of both accounts and preventing account takeover. You must trust the external IdP to provide accurate and secure user information to avoid potential security risks. If for example, the email address is not verified by the IdP, it can be a security risk.

Configure Your IAM as an OIDC Client

In your IAM system, configure a connection to the external IdP by acting as an OIDC client. The configuration involves:

• Registering the IdP: Add the OpenID Connect configuration endpoint or manual configuration, including endpoints, client ID, and client secret.
• Defining Scopes: Specify the scopes you need, such as openid, profile, email, or custom scopes provided by the IdP.
• Claim Mappings: Map the claims (user attributes) provided by the external IdP to your internal user schema.
• Token Validation: Set up token signature validation to ensure that tokens received from the IdP are authentic and secure before processing them.

Example Use Case

Imagine a company using Keycloak as its internal IAM federates with Google’s OIDC provider to enable Google logins for its applications. The integration involves:

• Registering Keycloak as an OIDC client in Google Cloud Console.
• Configuring Google as an IdP in Keycloak using Google’s metadata URL and client credentials.
• Mapping Google’s email and name claims to Keycloak’s user attributes.
• Testing the flow by logging in to an application and ensuring the session is established in Keycloak.

Warning: Mapping Considerations for Federation

When federating with external OIDC providers, it’s important to recognize that each provider may handle claims, scopes, and user attributes differently. These variations can significantly impact the integration process and require careful consideration during implementation.

Here a some common specificities existing with some providers:

• Custom Authorization Parameters (acr_values): Certain providers demand additional parameters, such as acr_values, during the authorization request to enforce specific authentication policies. For example, government-backed IdPs may require acr_values to indicate the desired level of assurance (LoA) for authentication.
• One-Time Attribute Availability: Some providers, like Apple, only return specific identity attributes during the first login for a given client. Attributes such as email or name may be provided during the initial authentication but are not available in subsequent logins. Instead, only the unique user identifier (sub) is returned.