When we deploy infrastructure for a community — a fire hall, a town office, a small organization — the services stack looks similar every time. Proxmox for virtualization. Nextcloud for files and collaboration. Matrix for chat. Gitea or Forgejo for code. Maybe Postgres for the database layer. The pieces are mature and well-documented.

The part that's always been harder than it should be is identity. Every service has its own user database. Every service has its own login flow. When someone joins the organization, you create accounts in five places. When someone leaves, you disable accounts in five places and hope you didn't miss one. When a password needs changing, it changes in five systems. SSO via Keycloak solves the login part — one credential, one authentication flow. But provisioning, deprovisioning, and security event propagation across services have been manual or required custom integration code.

Keycloak 26.7, released July 9, 2026, shipped a set of features that collectively close this gap. Not in theory. In practice, with APIs you can wire up today.

SCIM: Provisioning Without Custom Code

SCIM (System for Cross-domain Identity Management, RFC 7644) is a standard protocol for creating, reading, updating, and deleting users and groups across systems. It's been the "right answer" for automated user provisioning for years. The problem was that Keycloak didn't implement it as a server — you could use Keycloak as a SCIM client to provision users into other systems, but other systems couldn't provision users into Keycloak via SCIM.

Keycloak 26.7 adds a SCIM API as a preview feature. Full CRUD and PATCH operations, filtering, pagination, schema discovery, and the Enterprise User extension. You enable it with the scim-api feature flag.

What this means for a community deployment: when a new volunteer joins the fire hall, you create them once in Keycloak. Nextcloud, if configured as a SCIM client, sees the new user and provisions the account automatically. When they leave, you disable them in Keycloak and every connected service deprovisions on the next sync. No scripts. No manual account creation in five admin panels.

The SCIM API is preview, not supported — it may change before stabilization. But the specification is RFC 7644, and the implementation covers the operations that matter. For a community deployment where you control both ends, the risk of API changes between versions is manageable. Take a Proxmox snapshot before upgrading Keycloak and you're fine.

Shared Signals Framework: When "Disable" Actually Means "Disabled Now"

Here's a problem every federated identity deployment has: a user's account is disabled in the identity provider, but downstream applications don't find out until the next token refresh. If the access token has a 15-minute lifetime, the user has 15 minutes of continued access after being disabled. If the token lifetime is longer, the window is longer.

The OpenID Shared Signals Framework (SSF) fixes this. The identity provider pushes security events to downstream applications in near real time. When a user logs out, changes credentials, or gets disabled, every registered receiver knows within seconds, not minutes.

Keycloak 26.7 can now act as an SSF Transmitter. It supports CAEP 1.0 (Continuous Access Evaluation Profile) and RISC 1.0 (Risk and Incident Sharing) event profiles. Push delivery via RFC 8935, poll via RFC 8936. Events are persisted to a durable outbox so nothing is lost across restarts. Each realm opts in individually.

This is experimental — start Keycloak with the ssf feature flag. For a community deployment, the practical impact is significant: when you disable a user in Keycloak, Nextcloud and Matrix can know immediately instead of waiting for a token to expire. The security gap between "disabled in Keycloak" and "actually locked out everywhere" shrinks from minutes to seconds.

Not every downstream application supports SSF yet. But the applications that matter for community infrastructure are moving toward it. The framework is standards-based, so any application that implements the receiver side can subscribe. This is the kind of infrastructure that gets more valuable as more services support it.

AuthZen: Standardized Authorization Decisions

Applications that need fine-grained authorization — "can this user access this resource?" — typically call Keycloak's proprietary authorization API. This couples the application to Keycloak's internal model. If you ever want to swap the identity provider, you rewrite the authorization layer.

AuthZen (OpenID AuthZEN Authorization API 1.0) defines a vendor-neutral protocol between Policy Decision Points and Policy Enforcement Points. The application sends a request describing a subject, resource, and action. The PDP returns permit or deny. The application doesn't need to know how the decision was made.

Keycloak 26.7 implements the AuthZen Evaluation API as a PDP. Single and batch evaluation endpoints. Enable with the authzen feature flag.

For community infrastructure, this is a forward-looking feature. Most community deployments don't need fine-grained authorization today — role-based access in Nextcloud and Matrix handles the common cases. But if you're building custom applications on top of the community stack, AuthZen lets you externalize authorization decisions to Keycloak without locking your application code to Keycloak's API. The day you need it, the capability is there.

MCP Authorization: Securing AI Tool Connections

The Model Context Protocol is becoming the standard way for AI applications to connect to external tools and data sources. If your community is running AI infrastructure — local LLMs, agent frameworks, retrieval pipelines — MCP is likely in the mix.

MCP version 2025-11-25 requires an authorization server that complies with the OAuth Client ID Metadata Document (CIMD) specification. Keycloak 26.7 includes experimental CIMD support, allowing it to serve as an authorization server for MCP clients. The 26.7 release adds integration documentation for Claude Code and Visual Studio Code as MCP clients, both using OAuth with PKCE and localhost callbacks.

This means AI tools can authenticate through Keycloak instead of using static API keys. For a community running sovereign AI infrastructure — local models, no external API dependencies — this is the piece that lets you put proper access control in front of the tool layer. Your Keycloak users get authenticated access to MCP tools. No API keys lying around. No shared credentials.

ID-JAG: Cross-Organization Token Exchange

When two organizations each run their own Keycloak, users crossing between them normally re-authenticate. The Identity Assertion JWT Authorization Grant (ID-JAG) lets one authorization server present a signed identity assertion to another, which issues an access token without requiring the user to log in again.

Keycloak 26.7 has partial experimental support — it implements the receiving server role, accepting ID-JAG assertions at the token endpoint and issuing access tokens. Enable with the identity-assertion-jwt feature.

This is the federation primitive for inter-community trust. If your fire hall's Keycloak trusts the neighboring town's Keycloak, a user from one community can access services in the other without a second login. This is what federation actually means at the identity layer — not just "our Matrix servers talk to each other" but "our users can use each other's services."

The implementation is partial. The full ID-JAG flow isn't supported yet. But the direction is clear, and the receiving-server role is the hard part. The sending side is straightforward JWT signing.

The Practical Stack

Here's what a community identity deployment looks like with Keycloak 26.7 as the layer:

  1. Keycloak is the identity provider. Users, groups, credentials, MFA. One place to manage accounts.
  2. Nextcloud connects via OIDC. User provisioning via SCIM if you enable it on both sides. Security events via SSF when Nextcloud supports the receiver role.
  3. Matrix (Continuwuity) connects via OIDC. The v26.6.0 release removed LDAP in favor of OIDC — Keycloak is the natural provider.
  4. Gitea/Forgejo connects via OIDC. SCIM support is available through community plugins.
  5. Custom applications use AuthZen for authorization decisions if they need fine-grained access control.
  6. AI tools authenticate through Keycloak as an MCP authorization server. No static API keys.
  7. Neighboring communities can establish cross-domain trust via ID-JAG when the full flow lands.

One identity provider. Five or more services. Provisioning, deprovisioning, security events, and authorization all flowing through a single management plane. That's the difference between "we can deploy this" and "we can operate this over time."

What's Production-Ready and What Isn't

Being honest about maturity:

  • SCIM API: Preview. The operations work, the spec is stable (RFC 7644), but the API surface may change before stabilization. Safe for community deployments where you control the upgrade cycle.
  • Shared Signals Framework: Experimental. The transmitter works, but you need receivers that support SSF. Check whether your downstream applications implement it before investing in the integration.
  • AuthZen: Experimental. Standards-based, but adoption is early. Forward-looking, not urgent for most community deployments.
  • MCP authorization server: Experimental, building on CIMD which is itself an emerging standard. The MCP ecosystem is moving fast. Worth tracking if you run AI infrastructure.
  • ID-JAG: Experimental, partial implementation. The full cross-domain flow isn't complete. Watch this space.

Keycloak 26.6 (April 2026) already shipped the supported versions of JWT Authorization Grant, Federated client authentication, Workflows, and zero-downtime patch releases. The 26.7 features are the next wave — they work, they're standards-compliant, but they carry the experimental label because the APIs haven't stabilized. For a community deployment where you can test before upgrading and snapshot before changes, the risk is acceptable. For a production enterprise deployment with strict change management, wait for the supported promotion.

Why This Matters

The identity layer is the part of community infrastructure that scales poorly without tooling. A three-person IT team can run Proxmox, Nextcloud, and Matrix. They cannot manually manage user accounts across five services for 200 users and stay ahead of joins, departures, role changes, and security incidents.

Keycloak has been the SSO solution for years. What 26.7 adds is the management layer around SSO — provisioning, deprovisioning, security event propagation, authorization externalization, and cross-organization trust. These are the features that let one operator manage identity for a multi-service community stack without writing custom integration code for every service.

The FOSS identity stack is now as mature as the FOSS virtualization stack (Proxmox), the FOSS collaboration stack (Nextcloud), and the FOSS messaging stack (Matrix/Continuwuity). The piece that was missing — practical, standards-based identity federation for small organizations — just shipped. It's labeled experimental, and some of it is. But the capabilities are real, the APIs work, and the standards they implement are the right ones.

For the communities we work with: deploy Keycloak alongside Nextcloud and Matrix. Enable SCIM. Wire up OIDC on every service. When SSF receivers land in Nextcloud and Matrix, enable that too. The infrastructure for community-owned identity is here. Use it.