Run every B2B customer on one Keycloak, each with separate users and sign-in

We work out how tenants are structured in your B2B product, from how customers are onboarded to how your app learns which tenant a user belongs to.

Sound familiar?

Which of these sounds like your team?

B2B customers with different rules

No two customers want the same users, roles or login policy.

Pushback from enterprise IT

Your largest accounts' IT teams ask why their staff need yet another password.

Every new customer is a project

Someone on your team configures each one by hand before its users can log in.

Which company is this user from?

Your app can't decide what a user may do until it knows which company they work for.

A realm per customer seemed simple

Now every configuration change has to be repeated across all of them.

Support staff acting as user admins

Your people spend time adding and removing accounts that customers could handle themselves.

Process

How we work

  1. 01

    Design the model

    We lay out tenants to suit the number of customers you expect and how far apart they must be kept.

  2. 02

    Pilot

    We bring a small set of existing customers onto it before anyone else.

  3. 03

    Open it to everyone

    Every customer then gets the new onboarding, its own roles and, where wanted, its own SSO.

  4. 04

    Keep pace with new tenants

    Before each big jump in customer numbers, we put the system under simulated load.

Specifics

Technical details

  • How many tenants you expect, and how hard the walls between them must be, decide between per-customer realms, Organizations in one realm, or groups
  • A new user can arrive three ways: an emailed invite, their company's SSO, or an admin creating the account
  • When someone types their email, the domain decides which organisation's identity provider they are sent to
  • Each tenant can give its users different roles in each of your applications
  • Your app reads the user's organisation straight from the claims in each token
  • Customer admins get a scoped console where they invite and remove their staff

Options

Flexible to fit you

  • Give each customer a realm of its ownorKeep customers as Organizations in one realm
  • Everyone signs in through your login pageorCustomers sign in through their company's IdP
  • New customers register themselvesorYour staff set up each new customer
  • Your staff handle every customer's accountsorCustomers add and remove their staff themselves
  • Grootan runs the platformorYour engineers run it after launch

Measurement

What we measure

  • How quickly a new customer's people can first sign in
  • Customers a single Keycloak deployment can carry
  • How often sign-in fails, for any tenant
  • Which customers need the most help from your team

FAQ

Questions we hear

When do separate realms stop making sense?

When the count climbs. For a handful of customers that need hard separation, a realm each works well. Past that, the upkeep grows with every realm, and Organizations inside a single realm are easier to run.

Can a customer sign in through its own IdP?

Yes. Link an organisation to its company's provider, and anyone with that email domain is sent there to log in.

How does our app find out which tenant a user belongs to?

It reads it from the token. Keycloak includes the user's organisation as a claim.

How do you work out a price for this?

Each platform's scope and complexity are different, so pricing is a conversation for the first call.

Plan a tenant setup that keeps up with your customer list

Related

More Keycloak services