Keymate vs Native Keycloak
Summary
Keycloak is a powerful open-source identity and access management platform. It excels at authentication, SSO, user federation, and basic RBAC. However, enterprise environments frequently outgrow its native authorization capabilities. Keymate extends Keycloak by adding fine-grained authorization, multi-tenant organization management, policy lifecycle governance, and decision observability without replacing or forking Keycloak.
Why It Exists
Organizations adopt Keycloak for its strong authentication capabilities and open-source foundation. As their access governance needs grow, they encounter three recurring limitations:
- Authorization is limited to basic RBAC: Keycloak's native authorization services provide role-based checks, but lack contextual attributes, relationship-based decisions, risk-adaptive controls, and data sensitivity awareness.
- Multi-tenancy requires workarounds: Keycloak realms provide some isolation, but multi-tenant B2B/B2B2C/G2C topologies need first-class tenant management, organizational hierarchy, and delegated administration. These capabilities are not native to Keycloak.
- Policy decisions are opaque: There is no built-in policy lifecycle (versioning, review, approval, rollback), no "why denied?" analysis, and limited observability into authorization decisions.
How It Works
Feature Comparison
| Capability | Native Keycloak | Keycloak + Keymate |
|---|---|---|
| Authentication & SSO | Full support (OIDC, SAML, Social) | Unchanged. Keycloak handles authentication |
| User Federation | LDAP, Active Directory, custom | Unchanged. Keycloak handles federation |
| Basic RBAC | Global roles, client roles | Enhanced: scoped roles, tenant-aware, delegated assignment |
| ABAC (Attribute-Based) | Limited (via custom mappers) | Full support: user, resource, and environmental attributes |
| ReBAC (Relationship-Based) | Not supported | Full support via managed FGA engine backend |
| RADAC (Risk-Adaptive) | Not supported | Device posture, geolocation, behavioral risk signals |
| DSAC (Data Security) | Not supported | Data sensitivity classification and policy enforcement |
| Policy Aggregation (PBAC) | Basic | Composable strategies: unanimous, affirmative, consensus |
| Multi-Tenant Organization | Realm-based (limited) | First-class tenants, org trees, scoped administration |
| Delegated Administration | Not supported | Tenant and org-level admin delegation within boundaries |
| Policy Lifecycle | No versioning or approval | Version, diff, review, approve, simulate, rollback |
| Policy Simulation | Not supported | Dry-run, what-if analysis, decision tracing |
| Why-Denied Analysis | Not supported | Full breakdown of failed conditions and missing attributes |
| API Gateway Enforcement | Not native | API gateway plugins for edge enforcement |
| Service Mesh Enforcement | Not native | Service mesh filters for service-to-service authorization |
| OpenTelemetry Observability | Not native | Full instrumentation for auth and event pipelines |
| Audit Logging | Basic event logging | Structured, queryable, tenant-aware audit trails |
| Parallel Run / Migration | Not supported | Side-by-side evaluation with legacy IAM for safe cut-over |
RBAC: Native vs Enhanced
A closer look at how Keymate enhances Keycloak's role-based access control:
| RBAC Feature | Native Keycloak | Keycloak + Keymate |
|---|---|---|
| Global-only roles | Yes | Yes + Scoped roles |
| Static evaluation | Yes | Live evaluation at runtime |
| Multi-tenant aware | No | Yes |
| Delegated role assignment | No | Yes |
| Risk/context integration | No | Yes |
| Built-in audit logs for role decisions | No | Yes |
Boundaries
warning
Keymate does not replace Keycloak. It extends it.
- Keymate is not a fork. It integrates with Keycloak through standard protocols and APIs. Keycloak upgrades are independent of Keymate.
- Keymate does not handle authentication. Login flows, SSO, user federation, and token issuance remain Keycloak's responsibility.
- No migration is required. Users, clients, realms, and authentication flows stay in Keycloak unchanged. Keymate adds an authorization and governance layer on top.
Diagram
Common Misunderstandings
- "Keymate is a Keycloak fork." Keymate is not a fork. It is a separate platform that integrates with Keycloak through standard protocols. You continue to upgrade Keycloak independently.
- "We need to migrate users or realms." No migration is required. Your existing Keycloak setup (users, realms, clients, authentication flows) remains unchanged. Keymate adds authorization and governance capabilities alongside Keycloak.
- "Adding Keymate means rewriting our applications." Edge enforcement via API Gateway plugins and service mesh filters requires no application code changes. SDK-based enforcement requires minimal integration where needed.
- "Keycloak's built-in authorization services do the same thing." Keycloak's authorization services provide basic policy evaluation, but lack multi-tenancy, relationship-based access, risk-adaptive control, policy lifecycle management, simulation, and decision observability.
Design Notes
tip
Parallel run strategy: Deploy Keymate alongside your current authorization setup. Both systems evaluate the same requests. Compare decisions, identify mismatches, and fix policy intent before cutting over. This eliminates the risk of a big-bang migration.
- Minimal code change: Start with API Gateway enforcement for zero-code integration, then add SDK-based checks where fine-grained control is needed within application logic.
- Incremental adoption: Begin with one authorization model (e.g., scoped RBAC), add ABAC attributes, then layer ReBAC and RADAC as your observability matures.