Keycloak Organizations for B2B multi-tenancy guide

How Keycloak Organizations manage B2B customers inside one realm

If your business customers each bring their own staff, email domains and sign-in rules, the Organizations feature in the Keycloak server administration guide is the built-in way to group those members, their domains and their identity providers per customer inside one realm. Each organization acts as a container: you attach the customer's domains, add its users and, where needed, link an identity provider to it. That keeps one realm, one set of clients and one administration model, which is often simpler to operate than a realm per customer. The model is easy to describe, but several parts need more design work than a first demo suggests.

Domain routing is the first hard part. A user who enters an email address should reach the right organization and the right sign-in method, and that mapping must hold when a customer adds a domain, uses a subsidiary domain, or has staff who sign in with a personal address. Decide who may claim a domain and how ownership is verified before customers or your own staff can add one. Delegation is the second part. Customer administrators often need to manage their own members without seeing other customers' users, groups or clients. Map each delegated role to the exact administrative permissions it needs, then test that a customer administrator cannot read another organization's members through the admin console or the Administration REST API.

Onboarding is the third. Inviting members one at a time works for a pilot but becomes unmanageable when a customer brings hundreds of staff. Decide how members enter the organization: by invitation, by a feed from the customer's own directory, or through your provisioning code calling the admin API. Each method handles duplicates, departed staff and password resets differently, so write those rules down before go-live. Confirm the batch and invitation behavior your target version supports by reading the server administration guide for that release and testing it in a non-production realm built from the same version. The current Keycloak release is 26.8.1, so check its upgrade notes if you plan to run that version or an earlier one in production.

Two sibling topics go deeper. The identity brokering guide covers configuring a customer's OIDC, SAML or social identity provider, first login flows, account linking and attribute mapping. The implementation plan covers phasing, roles and the internal team time to budget. This section stays on the organization model itself. Before you commit, list which customers need their own sign-in rules, which need only membership and domain routing, and whether any customer requires isolation strong enough that a separate realm is the safer choice. Ask your partner or internal team to demonstrate each case on your target version before you build around it.

One realm with Organizations or separate realms per customer

This table compares three ways to model business customers in Keycloak: one shared realm using Organizations, one realm per customer, and a hybrid that gives regulated or high-sensitivity customers their own realm. Read each row as a decision you face, then check the operational cost on the right before choosing. For most B2B products with many similar customers, a shared realm keeps operations simpler, while separate realms become worth their overhead when isolation or compliance scope demands it.

Decision factor	One shared realm with Organizations	One realm per customer	Hybrid: shared realm plus dedicated realms
Number of customers	Fits large numbers of similar customers that share one login experience and one set of clients	Fits a small number of customers, since each realm adds its own configuration to maintain	Fits a large shared base with a short list of customers that need separation
Isolated configuration	Shared authentication flows, clients and themes apply to all organizations; per-organization identity providers are scoped to members	Each customer can have its own flows, themes, clients and providers without affecting others	Standard customers stay on shared settings; listed customers get their own flows and providers
Admin delegation	Organization administrators can manage members within their organization; confirm the exact permissions your version grants	Delegation is coarse: realm administrators can reach everything inside that realm	Delegation is per organization for shared customers and per realm for dedicated ones
Compliance scope	Assessors will review how organization boundaries are enforced inside one realm; document that evidence carefully	Each realm can be scoped, reviewed and evidenced separately, which often simplifies scope arguments	Dedicated realms cover the sensitive scope; shared realm controls must still be evidenced
Client and role sprawl	Low: one set of clients and roles serves all customers, with organization membership carrying the difference	High: clients, roles and mappers are duplicated per realm and drift over time without automation	Moderate: shared clients plus a growing list of dedicated realm configurations to keep aligned
Upgrade and export work	One realm to test and migrate for each Keycloak upgrade	Each realm must be tested, exported and reviewed on every upgrade, so effort grows with realm count	Shared realm work plus a repeatable test for each dedicated realm
Testing effort	One test suite covers sign-in, member onboarding and per-organization identity providers	Each realm needs its own regression tests, and differences between realms must be tracked	Two test patterns to maintain; keep dedicated-realm tests generated from the same template
Cross-customer reporting	Straightforward: user and event data sit in one realm, though events still need filtering by organization	Harder: reports must query or combine data from many realms	Shared data reports stay simple; dedicated realms need a separate reporting path

What organization domains change at sign-in

Organization domains decide where a user goes when they type an email address on the sign-in page. In Keycloak Organizations, a domain attached to an organization tells the realm that users with that email suffix belong to that business customer, so the login flow can route them to the organization's own sign-in path, such as its linked identity provider. Before you configure anything, settle this routing map on paper, because a domain that points to the wrong organization sends a user to the wrong identity provider or the wrong set of rules. Start with an inventory of the domains each customer actually owns. Ask every customer for the email domains their staff use, and separate primary domains from legacy or acquired ones. Confirm that one customer does not claim a domain another customer also needs, and decide who owns subdomains such as a regional subsidiary. Record the owner, the reason for the claim and the person at the customer who can prove control. This list becomes your change record and your evidence that domain ownership was checked, which matters when a customer later disputes access. Next, decide what happens when a domain is shared, unverified or unclaimed. Confirm in the server administration guide for your version whether Keycloak requires domain verification before a domain takes effect, and whether one domain can belong to more than one organization. If verification is optional in your version, decide whether you will accept unverified claims at all. For a user whose domain is outside every organization, decide whether they fall back to the realm's standard sign-in, see a generic registration page, or are refused. Write down each answer, because a silent default here is the most common source of unexpected access. Verify exact matching behavior before you rely on it. Check in the server administration guide for the version you will run how domains are matched, including case sensitivity, subdomain handling and how an address with a plus sign or a changed suffix is treated. Do not assume these rules from another identity product. Keycloak also documents Organizations administration as part of the same guide, so confirm each behavior against the release you will deploy rather than a newer one. Finally, test the routing with real test accounts before go-live. Create one account per case: a member of each organization, a user on an unclaimed domain, a user on a shared domain and an address with mixed case. Sign in through each path and record which organization and sign-in method applies. Repeat the test after every domain change and after each Keycloak upgrade, since routing behavior can change between releases. Keep the results with your rollout record so the routing decisions can be reviewed by your security team and by the customer.

Building the organization model in one realm, step by step

This sequence takes a team from confirming that the Organizations feature fits its Keycloak version to a tested model in which each business customer has its own domains, members, and access rules inside one realm. Each step ends with a check so the next step builds on verified behavior.

Confirm the Organizations feature for your version
The platform owner checks the Keycloak server administration guide and the release notes for the exact version you plan to run, because the Organizations behavior and its enablement can differ between releases. The current release listed on keycloak.org is 26.8.1, but the version you deploy is the one that matters. Confirm whether the feature needs to be enabled explicitly and which upgrade notes touch it. Output: a short written note naming the version, the documented behavior, and any open questions for the vendor or your partner. Check: a test instance shows the Organizations section in the admin console.
Design the customer model before creating anything
An architect works with the business owner to write the customer model down before touching the admin console. For each business customer, record a unique organization name and alias, the email domains that belong to it, a named internal owner, and any attributes the applications will need. Decide how new customers are named so that aliases stay consistent over time. Output: one register that lists every planned organization. Check: every domain appears in exactly one row, and every row has an owner, so no domain can resolve to two customers.
Create a test realm and the first organizations
The identity team creates a dedicated test realm, separate from any production realm, and turns on Organizations there. It then creates the organizations from the register, using the names and aliases exactly as written. Keeping the test realm isolated means that configuration experiments do not reach customer sign-in. Output: a realm containing the planned organizations and nothing else. Check: the organization list in the admin console matches the register line for line, including names and aliases.
Register and verify organization domains
For each organization, the team adds its email domains and completes whatever verification the documentation describes for that version. Confirm the verification method and any manual steps in the vendor documentation before you start. Repeat this for every organization in the test realm. Output: a domain list per organization that matches the register. Check: entering a test address from each registered domain on the sign-in page routes to the correct organization, and an address from an unregistered domain does not route to any organization.
Attach identity providers per organization where needed
Only organizations that require their own corporate identity provider need one. The team configures an OIDC or SAML provider in the realm, then links it to the matching organization so that members from that domain sign in through their own directory. Organizations without this requirement keep local accounts or shared login methods. Output: a documented list of which organizations use which provider. Check: signing in with a test account from the first organization uses its provider, and the provider for another organization is not offered to that account.
Define shared clients, roles, and groups
The identity team defines the clients, client scopes, roles, and groups that every organization uses, once, in the realm. Applications keep a single client configuration, and organization membership determines who sees what, instead of creating a copy of each application per customer. Add the mappers that place organization context into tokens. Output: a written inventory of shared clients, roles, and groups with the mapper settings. Check: the realm holds one client per application, and a review of two test organizations shows no duplicated client or role definitions.
Onboard a pilot customer's members
The identity team, with the customer's administrator, adds the pilot customer's members to its organization using the method the documentation describes for your version. Start with two or three test accounts, then add real members once the pilot works. Assign roles or groups as defined in the shared inventory. Output: a list of pilot members with their organization and assigned roles. Check: each pilot member can sign in to a test application and appears only under the pilot organization in the admin console.
Review token claims and access rules
Before any production work, decode the tokens issued to a pilot member and to a user from a different organization. Confirm the name of the organization claim in your version's documentation, then verify that each token carries only the expected organization context. Next, test that the application rejects cross-organization access. Output: a signed-off test record covering token contents and access results. Check: the pilot member's token contains only the pilot organization, and the second user's access to the pilot application is denied.

Per-organization identity providers and member onboarding

Each organization in a Keycloak realm can have its own customer identity provider attached, so that a member signs in with their employer's OIDC or SAML login and lands in the correct organization. The design decision here is which organization owns which identity provider, and whether that provider is the only way in or one option among several. Before configuring anything, list every customer, record the protocol and metadata their identity team can supply, and confirm the email domains each organization will claim. Domain claims decide where a sign-in is routed, so overlapping or mistyped domains are the most common cause of members landing in the wrong place. Members can arrive in three ways: an administrator or organization admin sends an invitation, the member self-registers where the realm allows it, or the member is imported in bulk from a file or directory export. Invitations are the safest default for B2B customers because they tie the account to a known organization from the first step. Self-registration should be enabled only for organizations that have agreed to it, and imports need a documented owner and a repeatable process. Confirm with the vendor documentation for your Keycloak version which onboarding paths are supported and how each one behaves with organization domains, because the Organizations feature has changed across releases.

The first-login flow and account linking settings decide whether a brokered user is matched to an existing account or created as a new one. If a member already has a local account with the same email address, the first-login flow determines whether Keycloak links the two identities, asks the user to confirm, or stops and requires an administrator. Automatic linking on email alone can let an account from one organization be attached to a person who is actually employed by another, so review the trust level of each customer provider before enabling it. Attribute mappers should also be checked so that the organization membership is set from the claim or domain you intend, not from a value the external provider can change freely. The protocol-level details of brokering, including OIDC and SAML client settings, signing keys, metadata exchange and mapper syntax, are covered in the identity brokering topic and are not repeated here. Use that topic for configuration steps and focus on the onboarding decisions: which flow runs on first login, when linking is allowed, and what happens when a provider returns an email domain that no organization claims. Test each path with a non-production account from every customer provider before go-live, and record the expected organization for each test user.

Plan the offboarding path before the first member is onboarded. When a customer's employer leaves the platform, or a member leaves the employer, the organization membership, the linked identity and any local account must be handled in a defined order. Write a runbook that names the owner who receives the request, the steps to disable the organization's identity provider so new sign-ins stop, the process for removing or disabling members, and how active sessions and refresh tokens are ended. Decide in advance whether accounts are deleted, disabled or retained for audit, and who approves that choice. Include a check that confirms the removed organization can no longer sign in through any remaining path, such as a local password or a second provider. The runbook should also cover the data each organization keeps: application records tied to a user identifier, audit events and any export a customer requested. Confirm these retention and deletion rules with your legal and privacy owners rather than inferring them from Keycloak defaults. Rehearse the runbook once in a test realm with a dummy organization so the team learns which steps are manual. Keep the runbook under version control and review it whenever the Keycloak version changes, since administrative behavior can shift between minor releases.

How the Organizations design changes by deployment model

In this design, Keycloak nodes form one cluster spread across availability zones and share one database. Organization definitions, domains and member settings live inside the realm, so the realm is the unit you export, review and import. Teams usually make changes in a non-production realm, export the result, and import it into production during a planned change window.

Realm export and import: Export the realm with its organizations and domains, store the file under version control, and remove secrets before committing it.
Import behavior: Confirm how your target version handles organizations that already exist in the target realm, and test that behavior before the production import.
Promotion: Move the same export through development, test and production, supplying environment-specific values such as identity provider endpoints separately.
Unchanged elements: Organization domains, member onboarding and per-organization identity providers work the same way as in other designs.
Database requirement: The database must be synchronously replicated across the zones, and you should test failover before go-live.

Before relying on this design, confirm the replication setup and the import behavior for your Keycloak version in a test environment.

Keeping one customer's members out of another customer's data

In a shared realm, every organization's members sit in the same user store, so a single misplaced permission or domain can expose one customer's accounts to another. The controls below separate who can change organizations from who can change clients, protect the admin surfaces, guard customer identity provider secrets, and catch domain mistakes before they become sign-in problems.

Split organization and client administration

Assign organization management, such as creating organizations, adding members and editing domains, to a role that cannot change clients, redirect URIs or realm keys. Client administrators can then alter how applications trust tokens without also controlling which customer's users belong to which organization. Check that each administrator account holds only the roles its job requires, and review those assignments on a fixed schedule.

Restrict who can change domains

Organization domains decide which email addresses are routed to which customer, so changing a domain is a high-impact action. Limit that permission to a small named group and require a second person to review any change before it is saved. Keep a written record of each domain each organization owns so that reviewers can compare requests against the approved list.

Limit who can change identity providers

A per-organization identity provider decides how that customer's members prove who they are, so a change to it can grant access to people outside that customer. Keep identity provider creation and edits in the same restricted role as domain changes, and separate read-only access for support staff. Confirm in your own test realm which roles can view and edit provider settings before you rely on the separation.

Move the admin console and admin API off public paths

The production guide for Keycloak recommends serving the admin console and Administration REST API on a different hostname or context path from the public frontend URLs. Enforce this at the reverse proxy by allowing administrative paths only from internal networks or approved management addresses. Test that a request to an administrative path from the public internet is refused.

Protect customer identity provider secrets

Each customer's identity provider client secret grants trust with that customer's directory, so exposure of one secret affects only that customer but can still be serious. Store these values in a secrets manager outside the realm export, avoid pasting them into tickets or chat, and rotate them through a documented procedure. Confirm how your backups and realm exports handle these fields before you schedule them.

Detect misconfigured domains early

A domain registered to the wrong organization can let a user with a matching email address join a customer they do not belong to. Review the domain list on a schedule and alert when a domain is added, changed or claimed by a second organization. Compare the organization membership of recently created accounts against their email domains, and treat any mismatch as an incident to investigate.

What drives the effort on an Organizations rollout

This table lists the inputs that change the size of a Keycloak Organizations rollout and how to keep each one contained. Read each row as a lever: the first column names the driver, the middle column explains why it moves effort or cost, and the last column shows what your team can standardize before a quote is written. The main takeaway is that most cost growth comes from per-customer exceptions rather than from the number of customers alone.

Driver	Why it changes effort	How to keep it down
Customers and members	Every organization adds records to create, verify, test and support, and member volume drives invitation and access review work.	Use bulk onboarding through a repeatable script or API, and agree on a member lifecycle owned by the customer's admin.
Domains per customer	Each verified domain needs ownership checks and routing rules, and multi-domain customers add edge cases during sign-in.	Set a policy limiting domains per organization and require domain verification before the organization is activated.
Customer identity providers and protocols	Each per-organization OIDC or SAML provider needs its own configuration, attribute mapping, test cases and certificate or secret rotation.	Support a short list of approved protocols and mapper templates, and treat any new protocol as a separate change request.
Existing realm data to migrate	Moving current users, groups and client settings into organizations requires mapping, deduplication and a reconciliation pass.	Clean and classify source data before migration, and agree on which users become organization members in the first wave.
Shared clients and roles	Organization-scoped roles, client scopes and mappers must be consistent across customers, and changes affect every tenant at once.	Keep one shared client set with a small role catalog, and avoid cloning clients for individual customers.
Delegated administration	Customer admins who manage their own members need role boundaries, audit trails and tests that prove they cannot reach other tenants.	Define a fixed set of delegated actions, document them, and test cross-tenant access as part of each release.
Compliance evidence required	Assessors may ask for access reviews, change records, logging and proof of tenant isolation, which adds documentation and export work.	Confirm the evidence list with your assessor early, and build exports and review reports into the design rather than producing them by hand.
Number of environments	Each environment needs its own realm configuration, test data, deployment pipeline and promotion checks for organization objects.	Manage organization and client configuration as code and promote it through the same pipeline in every environment.

Testing that organization isolation holds and fails safely

Organization isolation in Keycloak Organizations should be proven by tests that try to break it, and each negative case needs an expected result written down before anyone runs it. The first case covers cross-tenant access. Sign in as a member of organization A and attempt to read or change organization B's members, domains and identity providers through the admin console, the Administration REST API and any self-service account pages. Each attempt should be denied and recorded in the admin events. Test the console and the REST API separately, because access checks for each path can be configured and broken independently.

The second case covers domain routing. Sign in with an address on a domain that no organization has claimed, and decide in advance whether that user is refused or sent to the documented fallback, such as a local realm login. Then test a domain claimed by organization B, used by someone who is already a member of organization A. Include case variations and subdomains of claimed domains. Confirm the exact domain matching and redirect behavior in the documentation for your Keycloak version, since mistakes in domain rules are a common source of unintended routing.

The third case covers removal. Remove a member from organization A, then check that their existing browser session and refresh tokens stop granting access. Under standard settings, access ends at the next token refresh within the configured token lifetime, so measure the window against the realm's actual token and session values, not the defaults you remember. Record the time from removal to the first denied refresh. Repeat the check for any client that uses offline tokens or long session settings, because those can extend the window well beyond the access token lifetime.

The fourth case covers a failed customer identity provider. Simulate organization B's provider being unreachable, returning an error, or rejecting a wrong client secret. The expected result is a generic sign-in failure that lists no other customer's providers, exposes no other issuer URLs and never routes the user through another organization's broker. Also check the event records. The Keycloak 26.8 upgrade notes say login failures are persisted to the database by default, so confirm where those records are stored and which administrators can read them.

Run these negative tests in a copy of production configuration, with the same realm settings, identity providers, proxy path rules and database type, not in a development realm. Keep the suite as scripted tests so the same checks run each time. Repeat the full suite after every Keycloak minor upgrade. The project ships four minor releases a year, so this is a recurring cost, and you should read each upgrade's notes for behavior changes that could alter these results. Ask your implementation partner to hand over the test scripts and dated results as part of the deliverables.

What to monitor, back up, upgrade and document after go-live

After go-live, five recurring tasks keep a Keycloak Organizations deployment observable, recoverable and current. They depend on each other: exported realm configuration captures organization definitions, upgrade reviews decide how schema migration runs, and the organization register records who owns each tenant.

Enable and watch management metrics

Start Keycloak with metrics enabled so Prometheus-format data is served at /metrics on the management interface, and keep that interface off public hostnames. Platform engineering owns the scrape configuration and alert rules, and the identity team reviews them after each release. Confirm that login failures and latency can be filtered by realm, because a problem in one organization's sign-in flow can be hidden in aggregate totals. Review alert thresholds whenever traffic patterns or organization counts change.

Export realm configuration on a schedule

Organization definitions, their domains and their identity provider links live in realm configuration, so a scheduled export is the main backup for tenant setup. The platform team owns the job and stores each export in version control, where changes can be reviewed and reverted. Before relying on an export, confirm in your version's documentation whether it includes organization members and how it handles client secrets and identity provider credentials. Test a restore into a non-production environment at least once.

Review upgrade notes for each minor release

The project plans four minor releases a year, and each one can change behavior. The 26.8 upgrade notes, for example, enforce SMTP StartTLS without plaintext fallback, require signature validation of backchannel logout tokens from external providers, persist login failures to the database by default, and recommend moving off the deprecated multi-site feature. The platform lead owns the review with a security reviewer and records the outcome before any operator or image change. Keep the operator on manual update approval so upgrades happen only when this review is complete.

Choose the database schema migration method

Keycloak applies database schema migrations automatically at startup by default. The upgrading guide also describes manual migration, where administrators apply the SQL themselves, which it suggests for large deployments. The database administrator and platform team decide which method applies to each environment before the upgrade window, then rehearse it on a copy of production data. Confirm the rollback path for the database as well as the container image, since a schema change may not reverse with a simple redeploy.

Keep an organization register current

Maintain one document that maps each organization to its email domains, linked identity providers, business owners and offboarding steps. The identity administrator updates it on every onboarding, offboarding or domain change, and application owners confirm their entries during each scheduled access review. The register matters most during offboarding, because removing a member or domain without the linked steps can leave access in place. Store it alongside the realm configuration exports so the two can be compared.

Questions buyers ask before building Organizations in Keycloak

What drives the cost of building Organizations in Keycloak?

The main drivers are scope and design choices, not the feature itself. Cost rises with the number of customer organizations, the number of identity providers each one brings, the number of environments, and how much onboarding and directory integration you need. Internal staff time is a cost even when no vendor is involved. A partner is paid for the work in the written scope. One-time costs include the realm strategy decision, configuration, testing, documentation and initial onboarding steps. Recurring costs include testing each upgrade, operating the platform and any support retainer. Ask a partner for a written scope that lists deliverables, environments, the number of identity providers and sample organizations covered, the test plan, the handover, exclusions and the assumptions about your team.

How long does Organizations setup in Keycloak take?

There is no fixed duration that applies to every deployment. Timing depends on the number of customer organizations, the identity providers each organization uses, the number of environments, and how many applications must honor organization claims. Existing directory integration and a clear realm strategy shorten the work, while unresolved identity ownership lengthens it. Ask for milestones and acceptance criteria in the written scope rather than a single end date. Confirm the Organizations behavior, including domain handling and invitation options, in the Keycloak server administration guide for the version you plan to run, because feature details change between releases.

What does our team need to provide for a Keycloak Organizations project?

Four inputs decide how smoothly the work goes. First, identity owners must confirm the directory sources, sign-in policies and how member accounts are created. Second, application owners must confirm which clients will use organization membership in tokens and how their apps read those claims. Third, you need a test customer organization with real-world sign-in patterns, such as a domain, an identity provider and a few test users, so the design is checked against a case that behaves like production. Fourth, leadership must decide the realm strategy: one shared realm with organizations or separate realms per customer. That decision drives most of the later configuration.

Can our platform team set up Keycloak Organizations alone?

Yes, for a small pilot with good documentation and existing Keycloak skills. A platform team that already runs Keycloak can configure a few organizations, test domain-based membership and document the steps. The gap usually appears as the number of organizations, identity providers and environments grows, when onboarding must be repeatable and audited. Teams without Keycloak experience should expect a learning curve in realms, clients, identity brokering and token mapping. Before committing, list who owns each identity decision, test one complete organization end to end, and compare the effort with a fixed-scope partner engagement.

Do Keycloak upgrades change how Organizations behave?

Upgrades can change behavior, so each one needs a test pass. Keycloak plans four minor releases a year and says breaking changes in a minor release will be opt-in. Read the upgrade notes for every version between your current release and the target, because they list behavior changes that can affect sign-in flows and tokens. Database schema migration runs automatically at startup by default, and administrators can apply it manually, which the upgrading guide suggests for large deployments. If you use the Keycloak Operator, the documentation strongly recommends manual approval for operator updates. Test your organization configuration in a non-production environment before every production upgrade.

When is a separate Keycloak realm safer than an organization?

Use a separate realm when a customer needs its own administrative and security boundary. Organizations suit business customers that can share one set of realm settings, clients and user pool while keeping their members, domains and identity providers distinct. Separate realms become the safer choice when a customer needs its own administrators with full control, different password or MFA policies, separate signing keys, distinct branding, strict data separation, or a compliance boundary that a shared realm cannot meet. Confirm the current limits of organizations, including which settings are realm-wide, in the Keycloak documentation for your version before you decide.

What should engineers verify when onboarding a new organization member?

Verify the complete path from invitation to token. Start with the organization domain and confirm that a user with a matching domain is routed to the right identity provider and organization. Check the invitation or join flow, the attributes mapped from the identity provider, and the claims that the client receives in its tokens. Test how an application reads organization membership, how a member who leaves the organization is removed, and whether delegated administrators can change only their own organization. Repeat these checks after every upgrade and document the expected results so that a new team member can rerun them.

How DeployOpen scopes, builds and hands over Organizations work

DeployOpen plans, implements and supports self-hosted Keycloak inside your own infrastructure, including the Organizations feature for business customers in a single realm. We start by agreeing which customers, domains, identity providers and realms the design must cover, then build and document it in your environment. Engagements are fixed-scope, and ongoing support is available as a retainer.

How we scope

Written scope lists the organizations, email domains and member onboarding paths the design must cover.
We record which organizations need their own identity provider and which share the realm's defaults.
Realm boundary decisions are documented, including when a separate realm is the better fit for a customer.

How we build

Configure the Organizations feature in your Keycloak version, with domains and membership set up for each business customer.
Attach per-organization identity providers and attribute mappers, tested with a sign-in from each organization's test account.
Build realm and client settings in a non-production environment before any change reaches production.

How we hand over

Deliver realm configuration as exported and version-controlled artifacts, with the steps to reproduce them.
Provide runbooks for onboarding a new organization, adding a domain and removing a member.
Walk your administrators through the admin console tasks, with written notes on what to check after each change.

How we support

Ongoing support, upgrades and testing are available as a retainer, scoped in writing.
Plan Keycloak upgrades with a test realm that includes your organization configuration and identity providers.
Monitor login failures and cache health through Prometheus metrics enabled on the management interface.

Keycloak Organizations for B2B multi-tenancy