Using Keycloak as a Unified IAM Broker to Address Federation and SAML Issues with Duende IdentityServer

Modern enterprise applications rarely rely on a single identity provider. Organizations often integrate with multiple external systems such as partners, SAML providers, and OIDC providers. Managing these integrations directly within an application or a single IAM system can quickly become complex, brittle, and difficult to scale.

In our implementation, we initially used Duende IdentityServer as the central IAM system. While Duende is powerful for OAuth2/OpenID Connect scenarios, we encountered challenges when integrating with diverse external identity providers, especially those using SAML. To address these challenges, we introduced Keycloak as an IAM broker, transforming our architecture into a unified, scalable, and flexible identity federation model.

This article explains the problem we faced, the solution we implemented, and how Keycloak helped us build a unified IAM layer.

By introducing Keycloak as a broker, we decoupled identity federation from application logic, enabling scalable onboarding of new identity provider without code changes.

Problem Statement

1. Multiple External Identity Providers

Our system needed to support authentication from multiple sources:

• SAML-based partner identity providers
• Internal users
• Potential future OIDC providers

Each provider had:

• Different attribute formats
• Different authentication flows
• Different security requirements

2. Limitations with Duende IAM

Duende IdentityServer is primarily designed for:

• OAuth2 / OpenID Connect flows
• Token issuance
• API authorization

However, we faced several challenges:

❌ SAML Support

Duende does not natively support SAML federation.
We had to rely on external components or custom implementations.

❌ Complex Federation Logic

All mapping logic had to be implemented manually:

• Attribute transformation
• Claim normalization
• Partner-specific logic

❌ No Central Federation Layer

Each new partner integration required:

• Custom code changes
• Testing overhead
• Risk of breaking existing integrations

❌ Lack of Standardized Identity Contract

Different IdPs returned different attributes, leading to:

• Inconsistent claims
• Difficult user provisioning
• Increased validation complexity

3. Real-World Example of the Problem

We received SAML assertions like:

<saml:Attribute Name="userid">userId123</saml:Attribute>
<saml:Attribute Name="email">user@example.com</saml:Attribute>
<saml:Attribute Name="phone">123456789</saml:Attribute>

Each partner could send:

• Different attribute names
• Missing fields
• Multiple role values

Handling this directly in Duende became difficult and error-prone.

Solution: Introducing Keycloak as IAM Broker

To solve these problems, we introduced Keycloak as an identity broker between external IdPs and Duende.

High-Level Architecture

External IdP (SAML/OIDC)
        ↓
   Keycloak (Broker)
        ↓
   Duende IAM (OIDC)
        ↓
   Application / Mobile

Why Keycloak?

Keycloak provides:

• ✔ Native SAML and OIDC support
• ✔ Built-in identity brokering
• ✔ Flexible attribute mapping
• ✔ Protocol translation (SAML → OIDC)
• ✔ Centralized identity management

How the Solution Works

Step 1: External Authentication (SAML)

User logs in via partner IdP.

User → Partner IdP → Keycloak Broker

Step 2: Keycloak as Broker

Keycloak:

• Validates SAML response
• Extracts attributes
• Maps attributes to internal format
• Converts SAML → OIDC

Step 3: Canonical Identity Mapping

We defined a canonical identity contract:

{
  "sub": "userId123",
  "userid": "userId123",
  "phone": "123456789",
  "email": "user@example.com"
}

Keycloak maps incoming SAML attributes into this structure.

Step 4: OIDC Token Issued to Duende

Keycloak acts as an OIDC Identity Provider for Duende.

Keycloak → Duende (/authorize → /token)

kc_idp_hint=test-saml-hint

{
  "alias": "test-saml-hint",
  "providerId": "saml",
  "enabled": true
}

Client: keycloak-oidc-client
Protocol: OIDC
Redirect URI: https://app/callback