Federated Identity Management for B2B SaaS on Skycloak Organizations

Enterprise customers expect to log in to your SaaS application with their existing corporate credentials. They already use Microsoft Entra ID, Okta, or Google Workspace for workforce identity, and they want single sign-on (SSO) to your product without creating new accounts or managing separate passwords. That expectation is federated identity management: you delegate authentication to each customer’s identity provider while maintaining one consistent identity layer for your application.

This guide explains federated identity management for B2B SaaS, when to use the Organizations feature in Keycloak vs realm-per-tenant, and how to configure Skycloak or upstream Keycloak to support multiple enterprise customers with their own identity providers.

What is federated identity management?

Federated identity management (FIM) means accepting authentication assertions from external identity providers you do not control. Instead of storing usernames and passwords for every user, you trust identity providers that already know who those users are.

In B2B SaaS, FIM typically means:

1. Customer A uses Okta. Users from Customer A authenticate with Okta.
2. Customer B uses Entra ID. Users from Customer B authenticate with Entra ID.
3. Your application trusts your identity hub (Keycloak or Skycloak). Your app receives tokens from one place regardless of which customer the user belongs to.
4. Your hub federates to each customer’s IdP. Keycloak handles the protocol details (SAML, OIDC) and routes users based on their email domain or organization membership.

FIM keeps identity provisioning and deprovisioning in the customer’s hands. When a customer’s IT admin revokes an employee’s account in Entra ID, that user immediately loses access to your application.

Why B2B SaaS needs federated identity

Enterprise buyers require SSO. It shows up in security questionnaires, in procurement checklists, and in contracts. Without FIM:

1. Every user needs a separate account in your system. You store passwords, handle resets, enforce MFA separately, and own the security risk.
2. Offboarding is manual. When an employee leaves Customer A, Customer A’s IT team must notify you to disable the account. That delay is a security gap.
3. Compliance friction. Customers want centralized access logs, audit trails, and policy enforcement in their own IdP. Without FIM, your app is a blind spot.
4. Sales cycles lengthen. Enterprise deals stall on “we need SAML SSO,” and if you do not have it, you lose to competitors who do.

With FIM, customers bring their identity infrastructure, you plug into it, and their existing access controls, MFA policies, and provisioning workflows apply automatically.

Organizations vs realm-per-tenant

Keycloak gives you two ways to architect B2B multitenancy:

1. Organizations feature (single realm). Multiple customers (Organizations) exist in one Keycloak realm, each linked to its own identity provider and email domain. Introduced in Keycloak 25, this is the recommended default for most B2B SaaS.
2. Realm-per-tenant. Each customer gets a dedicated Keycloak realm. Use this only when customers require hard isolation of configuration, branding, or admin access.

For deep performance and scaling numbers, see Multitenancy in Keycloak Using the Organizations Feature and Keycloak Realm Scaling: How Many Realms Per Cluster.

This guide uses the Organizations approach because it fits the majority of B2B use cases. If you need realm-per-tenant, the IdP setup steps are identical, you just repeat them in each realm.

Organizations feature overview

The Organizations feature lets you create multiple tenants inside one Keycloak realm. Each Organization has:

• A unique domain (e.g., acme.com).
• A linked identity provider (OIDC or SAML).
• Members (users who authenticated via that IdP and domain).

When a user enters user@acme.com at the login page, Keycloak matches the domain to the acme.com Organization and redirects them to the linked IdP (Okta, Entra ID, etc.). The user authenticates there, and Keycloak creates or updates their local account under the acme.com Organization.

Prerequisites

1. Keycloak 25+ (this guide uses 26.x; the feature arrived in 25).
2. Organizations feature enabled for your realm: Realm Settings > Turn On Organization.
3. An external identity provider configured in your realm (OIDC or SAML).

For managed hosting, Skycloak runs upstream Keycloak with the Organizations feature available by default.

How to configure an Organization in Skycloak

This setup follows the Skycloak identity providers documentation and the Keycloak Organizations guide.

Step 1: Add an identity provider (realm-level)

Before creating an Organization, add the customer’s identity provider at the realm level. Organizations link to existing IdPs, they do not create new ones.

For OIDC IdPs:

1. Go to Identity providers > Add provider > OpenID Connect v1.0 (or select a specific provider like Google or Azure).
2. Enter the provider alias, display name, client ID, client secret, and discovery endpoint.
3. Set Trust email to On if the IdP is trusted.
4. Set First login flow to first broker login.
5. Click Add.

For SAML IdPs:

1. Go to Identity providers > Add provider > SAML v2.0.
2. Import the IdP’s metadata XML or URL.
3. Configure the alias, display name, NameID format, and trust settings.
4. Click Add.

Add one IdP per customer. If Customer A uses Okta, add an acme-okta IdP. If Customer B uses Entra ID, add a contoso-entra IdP.

For step-by-step SAML setup, see How to Set Entra ID SAML in Keycloak as an IdP.

Step 2: Create an Organization

1. Go to Organizations (new menu item after enabling the feature).
2. Click Create organization.
3. Enter a Name (e.g., Acme Corp).
4. Enter an Alias (e.g., acme).
5. Add a Domain (e.g., acme.com). This must be unique per realm.
6. Click Create.

Step 3: Link the identity provider to the Organization

1. Select the Organization you just created.
2. Go to the Identity Providers tab.
3. Click Link Identity Provider.
4. Select the IdP you created in Step 1 (e.g., acme-okta).
5. Enable Redirect when email domain matches if you want automatic routing (recommended).
6. Click Save.

Now, when a user enters user@acme.com, Keycloak redirects them to the acme-okta IdP automatically.

Step 4: Test the integration

1. Open your application (or the Keycloak account console).
2. Enter an email address with the organization’s domain (e.g., testuser@acme.com).
3. You should be redirected to the external IdP (Okta, Entra ID, etc.).
4. Authenticate there.
5. You should be redirected back to Keycloak and logged in.
6. Verify the user appears under Organizations > [Your Org] > Membership as a managed member.

Organizations per-organization IdP linking (current limitation)

As of Keycloak 26.x, the Organizations feature supports realm-level identity providers that are then linked to each Organization. You create one IdP in the realm’s Identity Providers section, then link it to an Organization.

What is not yet available: A per-organization IdP dashboard where you create and manage IdPs scoped to a single Organization without touching the realm-level IdP list. This is a natural evolution of the feature and is tracked in the upstream Keycloak roadmap and in the Skycloak product backlog.

Current workaround: Create realm-level IdPs with descriptive aliases (e.g., acme-okta, contoso-entra) and link them to the appropriate Organization. This works well and is the supported pattern today. The only difference from a dedicated per-org IdP UI is that all IdPs appear in the realm’s Identity Providers list.

Add organization claims to tokens

To include organization context in the tokens your application receives, add the organization scope to your OIDC client.

Step 1: Update your application’s OAuth scope

In your app’s OAuth configuration, request the organization scope:

# Spring Boot example
spring.security.oauth2.client.registration.keycloak.scope=openid,profile,email,organization

Step 2: Enable organization attributes in the token

1. Go to Client Scopes and select organization.
2. Open the Mappers tab and select the organization mapper.
3. Toggle Add organization attributes to On.
4. Toggle Add organization id to On.
5. Click Save.

Now your application receives the organization ID and any custom organization attributes in the access token. Use the JWT Token Analyzer to inspect the result.

Domain routing for multiple organizations

Once you have multiple Organizations configured, domain routing is automatic (if you enabled Redirect when email domain matches when linking the IdP). When a user types user@acme.com, Keycloak routes them to the acme-okta IdP. When they type user@contoso.com, Keycloak routes them to the contoso-entra IdP.

Rules for domain routing

1. Each Organization must have a unique domain. You cannot assign acme.com to two different Organizations.
2. Each Organization must link to a unique IdP. You cannot link the same IdP to multiple Organizations (this is a design constraint to keep routing deterministic).
3. One domain per Organization. If a customer uses multiple domains (acme.com, acme.co.uk), add them both to the same Organization.

For more on domain routing, see Multitenancy in Keycloak Using the Organizations Feature.

User provisioning with SCIM

Organizations handle just-in-time (JIT) provisioning: when a user logs in for the first time, Keycloak creates their account automatically. For proactive provisioning (creating accounts before first login) or deprovisioning (removing accounts when users leave), use SCIM 2.0.

Skycloak supports SCIM for user provisioning from Okta, Entra ID, and other SCIM-compliant IdPs. See Using SCIM 2.0 with Skycloak Managed Keycloak and the SCIM feature page.

Keycloak-native Organizations and exportability

The Organizations feature is part of upstream Keycloak, not a vendor-specific extension. Your configuration is portable: if you start on Skycloak and later move to self-hosted Keycloak, your Organizations and IdP links export cleanly as standard Keycloak JSON.

This matters for enterprise procurement. Buyers want SSO and federation, but they also want to know they are not locked into a proprietary system. Keycloak (and Skycloak) deliver both.

For export procedures, see Migrating Self-Hosted Keycloak to Skycloak (the reverse path works the same way).

Frequently asked questions

What is federated identity management in B2B SaaS?

Federated identity management in B2B SaaS means accepting authentication from each customer’s existing identity provider (Okta, Entra ID, Google Workspace, etc.) instead of managing usernames and passwords yourself. Each customer brings their own IdP, you link it to their organization in your identity hub (Keycloak or Skycloak), and users authenticate with their corporate credentials.

Do I need a separate Keycloak realm for each customer?

Usually no. The Organizations feature lets one Keycloak realm serve multiple customers, each with their own IdP and domain. Use separate realms only when customers require hard isolation of configuration, branding, or admin access. Organizations is simpler to operate and is the recommended default.

How does Keycloak know which IdP to use for each user?

By email domain. Each Organization is assigned a unique domain and linked to one identity provider. When a user enters their email, Keycloak matches the domain to the Organization and redirects them to the linked IdP. This happens automatically if you enable Redirect when email domain matches when linking the IdP.

Can I use SCIM to provision users into Organizations?

Yes. Skycloak supports SCIM 2.0 for proactive user provisioning and deprovisioning. Configure SCIM in your customer’s IdP (Okta, Entra ID, etc.) to push user lifecycle events to Keycloak. See Using SCIM 2.0 with Skycloak Managed Keycloak and the SCIM Endpoint Tester tool.

Is the Organizations feature vendor-specific or part of upstream Keycloak?

The Organizations feature is part of upstream Keycloak (introduced in version 25). It is not a Skycloak-specific extension. Your configuration exports as standard Keycloak JSON and works on any Keycloak 25+ instance.

Conclusion

Federated identity management is table stakes for B2B SaaS. Enterprise customers bring their own identity providers, and the Organizations feature in Keycloak (and Skycloak) handles the federation, domain routing, and user lifecycle without requiring separate realms or custom code.

The current implementation uses realm-level identity providers linked to Organizations, which works well for most deployments. Per-organization IdP management (a dedicated dashboard for creating IdPs scoped to a single Organization) is a natural next step and is tracked in the Skycloak product backlog.

For a general introduction to federated SSO architecture, see Federated SSO vs a Single IdP: When You Need an Identity Hub. For a canonical recipe for adding any OIDC or SAML IdP to Skycloak, see Skycloak Identity Providers Recipe.

For managed Keycloak hosting with Organizations, identity provider federation, and SCIM provisioning built in, see Skycloak’s Identity Providers feature or start with the Skycloak documentation.