76 posts tagged with "phase_two"

Keycloak publishes releases and container images for the current minor version only. It does backport selected security fixes to the two most recent even-numbered branches, and it tags them — but it cuts no GitHub release and builds no image from those tags. As of today there are nine such tags on release/26.4 and three on release/26.6, containing fixes for CVEs that were announced months ago, that you cannot docker pull from anywhere upstream.

Phase Two now builds them. quay.io/phasetwo/keycloak:26.4.16 and quay.io/phasetwo/keycloak:26.6.7 exist today, built from the tag's own Dockerfile, and we intend to keep building the two previous minor lines alongside the current one for as long as upstream keeps backporting to them.

We're shipping an experimental Telemetry Export for Enterprise Keycloak clusters. Point it at your own OTLP endpoint and your cluster's Keycloak logs and authentication events start arriving in whatever you already run — OpenSearch, Datadog, Grafana, SigNoz, Elastic, or your own OpenTelemetry Collector.

No agent to install, no log shipper to configure, and nothing to run on your side except the collector you already have.

Everything you can do in the Phase Two console, you can now do from code.

Create a dedicated Keycloak cluster. Add a realm to it. Attach a custom domain and watch the certificate get issued. Upload a custom provider. Restrict the admin console to your office IP range. Pull yesterday's logs.

Three things shipped together, because none of them is much use alone: the Management API, the API credentials that authenticate to it, and a Terraform provider generated from the same spec.

All three are experimental for now. The console marks API credentials as such, and the Terraform provider is at 0.1.0. Point them at test environments rather than production while the surface settles.

Today we're launching keycloak-skills — an open-source Agent Skills plugin that teaches Claude how to configure Keycloak correctly — and the Phase Two Keycloak MCP server, 158 admin tools that let it do the work against a live cluster instead of just telling you what to type.

Two commands to install. Works against any Keycloak — and gets sharper the closer you get to ours. Don't have a Keycloak yet? The agent can provision one for you and it's free for 30 days.

We're open-sourcing keycloak-atomic-auth-flows, a Keycloak extension that replaces an entire set of authentication flows, authenticator configs, and their bindings in one atomic, transactional request.

It was built in partnership with Gusto, who use Keycloak for user authentication and rely on Phase Two for enterprise Keycloak support. It has been running in their production environment for almost a year. The public repository is the extraction of that work into a standalone extension anyone can install.

Every login, logout, failed password attempt, and admin change in Keycloak produces an event. That's exactly what you want for security auditing and product analytics — until you realize where Keycloak puts them: in the same relational database that your authentication path depends on. At scale, event storage becomes a problem you can't ignore. Here's how we solved it, and how the key piece — an MDC-logging EventStoreProvider — is open source so you can solve it too.

Today we're launching a new way to run Phase Two: the Starter cluster tier, available at $149 per month. Starter bundles the same feature set as our existing dedicated clusters into a plan that's accessible for teams getting their use case off the ground or running development environments with lower SLA needs. It also includes a 30-day free trial, so you can validate your setup before committing.

Log into the dashboard and click Create Cluster to pick the new tier and provision yours.

Today we're launching Observability for dedicated Keycloak clusters — built directly into the Phase Two dashboard with zero setup. Requests, event data, and live logs are all there the moment your cluster is running. No agents to install, no log shippers to configure, no Prometheus, Grafana, or Loki stack to stand up and maintain.

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.