11 posts tagged with "organizations"

The login page is the most attacked page on an online store, and it is rarely the one anyone designed for attack. Homegrown e-commerce login usually starts as a users table, a bcrypt column and a session cookie, and it grows a password reset, a mobile API, a trade-account flag and a social button over the years. What it almost never grows is a defense against credential stuffing: automated replay of email and password pairs leaked from other sites, aimed at whichever of your customers reused one. Replacing homegrown login with Keycloak gives a store one identity service for web, app and back office, with social login, B2B accounts and branded pages built in, and you can move customers onto it without asking anyone to reset a password. It does not make the login page safe on its own. The defaults leave doors open that attackers look for first, and the rest of this post covers both halves: what you gain, and what has to be layered on top.

Migrating from Auth0 to Keycloak is three separate jobs wearing one name. Profiles move easily — Auth0's export job gives you newline-delimited JSON and Keycloak's partial-import endpoint takes it. Passwords do not move at all: Auth0 hashes with bcrypt, Keycloak 26.7.4 ships four password-hashing providers and none of them is bcrypt, so you either reset every password or stand up a bridge that verifies against the old hashes on first login. Your Rules and Actions have to be rewritten, because there is no equivalent runtime — some of them become authentication-flow configuration with no code at all, and some become a Java SPI.

The part that costs people a weekend is none of those. It is that Keycloak's admin API answers 201 Created to three different malformed migrations and then quietly loses the data. Everything below was run against Keycloak 26.7.4 on PostgreSQL 16.

SCIM — System for Cross-domain Identity Management — is a standard REST API for creating, updating, and deactivating user accounts across systems. SSO answers "can this person log in?" SCIM answers "does this person have an account at all, and should they still?"

If you sell to enterprises, you will be asked for it. This post covers what it is, when you actually need it, and a working walkthrough of Keycloak's native SCIM API — which arrived as a preview feature and is not enabled by default.

Everything here was run against Keycloak 26.7.3.

A few quarters ago you got handed a single-line ask: "we need enterprise SSO and directory sync by the end of the quarter." Maybe the deal was a Fortune-500 logo. Maybe it was a Series B requirement. Either way you found WorkOS, wired in their SDK in a long weekend, shipped the deal, and got the high five.

Then the renewal came in. The seat-based pricing, that sounded harmless when you had two customers using SSO, looks different when you have forty. Suddenly there's a line item on a board slide that scales linearly with your enterprise revenue — a parasite that eats into the very margin that the enterprise tier was supposed to fund. The CFO walks over and asks you to "fix it."

Here is the awkward truth nobody tells the engineer-on-the-spot: the WorkOS feature set has had a fully open-source equivalent for years. Keycloak handles SSO. Phase Two's organizations extension handles multi-tenant orgs. The identity provider wizard handles the same admin-portal flow your customers see in WorkOS today. The catch is that nobody wanted to spend the runway to migrate.

We've now built the tool that turns that "we'll deal with it later" debt into an afternoon of work. Why? Because WorkOS customers are starting to wake up to Keycloak, and they're coming to us in droves.

We're shipping experimental SCIM 2.0 provisioning for the Phase Two Organizations extension. Each organization in a realm can now act as its own SCIM 2.0 service provider, so an upstream IdP like Okta or Entra ID can push users into a specific tenant rather than into the realm as a whole.

This is the piece of the multi-tenant story that Keycloak's stock SCIM support doesn't address today, and it's been a heavily requested item from customers running Organizations in production.

Keycloak has exactly four theme types you can set on a realm: login, account, admin, and email. Each one is its own directory of templates, message bundles and static assets, packaged into a JAR and dropped into the server's providers/ directory. That is the whole extension point. It is also why custom Keycloak themes tend to become a standing maintenance cost: your templates are copies of upstream files, and upstream moves every release.

We've completely rebuilt our bundled Keycloak themes. What used to live as a tangle of custom pages inside a forked Keycloak repository is now a first-class Keycloakify-based React application that ships all four: login, admin, account, and email. The result is faster to maintain, far more capable, and dramatically better out of the box for the organizations using Phase Two today.

Switching themes is four realm fields. Set them in Realm settings → Themes in the admin console, or from the CLI. Verified against Keycloak 26.7.3:

kcadm.sh update realms/<your-realm> \
  -s loginTheme=phasetwo-ui \
  -s accountTheme=phasetwo-ui \
  -s adminTheme=phasetwo-ui \
  -s emailTheme=phasetwo-ui

Starting now, all Phase Two containers ship with this theme bundled. Any realm you create through the Phase Two Dashboard automatically gets the new login, admin, account, and email themes active, with no configuration required. The first time a user hits your login page or receives an email from your realm, it already looks good.

As more companies build SaaS platforms, the need to serve multiple customer groups—or tenants—from a single system becomes critical. In the identity world, this means implementing multi-tenancy within your identity provider.

In this post, we’ll walk through:

• What multi-tenancy means in Keycloak
• The drawbacks of using multiple realms for tenants
• Why organizations are a better, more scalable approach
• How the Phase Two Organizations extension supports advanced use cases like theming, shared IdPs, and user membership
• How our implementation differs from (and improves on) the new native Keycloak organizations feature

We've written extensively about how to model multi-tenancy with organizations and how Phase Two's Organizations extension differs from the native implementation being undertaken by the Keycloak team.

All of Phase Two's hosted environments come standard with all of our popular extensions to make it easy to hit the ground running and cover 95% of all IAM use-cases.

Overview​

A multi-tenant application is a software architecture where a single instance of an application serves multiple, distinct customer groups or “tenants.” Each tenant, often representing an organization or user group, shares the same underlying infrastructure and codebase but operates within its own securely isolated environment. This allows each tenant to have individualized data, configurations, and sometimes even unique customizations, while benefiting from a shared platform that reduces overall resource demands and maintenance. Multi-tenancy is commonly used in SaaS (Software as a Service) applications, enabling businesses to scale efficiently, lower costs, and streamline updates while ensuring that each tenant’s data and settings remain private and distinct from others within the same application. This approach is particularly valuable in enterprise applications, where companies may need to provide access to different organizations, departments, or customer groups within a single solution.

An exciting new feature has been added to Phase Two Organizations Extension! Organizations now support shared Identity Providers (IdPs) for mapping multiple organizations to a single IDP. This feature is especially useful for organizations that have multiple organizations that need to share the same IDP.

Since we first released our (most) popular Keycloak extension, Keycloak Organizations (Orgs) and made it available as open source on Github, the Keycloak maintainers have decided to build into native organization support.

This begs the question? What is different between Keycloak's upcoming organizations feature and the Phase Two Organization Extension?