Why Keymate
Summary
Enterprise IAM teams keep hitting the same walls: RBAC role explosion, multi-tenancy and delegation gaps, and invisible policy decisions. "Rip-and-replace" is risky; "do nothing" is riskier. Keymate takes a third path: layer intelligence and visibility on top of your existing Keycloak stack, run in parallel, and make access explainable and governable.
Why It Exists
1. RBAC Role Explosion and Context Blindness
Roles multiply as systems and use cases grow. In one real-world environment (approximately 650 roles across 9 applications and 120 tenants), role changes grew 35% year over year while audits slowed to a crawl. RBAC is foundational, but alone it cannot express who should access what, in which relationship, under which risk, and for how long without exploding into ad-hoc roles and exceptions.
Roles lack the ability to encode attributes (department, region, data classification), relationships (owner, manager, collaborator), or risk signals (device posture, anomalous geolocation, after-hours access). Without context, you either over-grant or drown in access request tickets.
2. Multi-Tenancy and Delegated Administration Gaps
B2B, B2B2C, and G2C topologies require strict tenant isolation, organizational hierarchy, and clean delegation. Without a first-class model, operations slide back to ad-hoc emails and manual approvals. This approach is brittle, slow, and audit-unfriendly.
Encoding tenant or organizational structure into role names (e.g., admin_acme_us_sales_rw) guarantees sprawl and confusion. Tenants, org trees, and scopes must exist outside roles as first-class authorization primitives.
3. Policy Lifecycle and Invisibility
Policies should behave like software: versioned, reviewed, approved, tested, and rolled back. In practice, approvals are informal, diffs get lost, and when access is denied there is no explainable trace to show which rule fired. If decisions are not observable, risk management turns into guesswork.
Where It Fits in Keymate
Keymate represents a third way between two common extremes:
| Approach | Risk |
|---|---|
| Rip-and-replace | Months of rewrites, disruption, and migration risk |
| Do nothing | Compliance pressure, audit costs, and operational drag compound over time |
| Keymate (augment) | Layer on top of existing IAM, run in parallel, cut over gradually |
Keymate does not replace Keycloak. It strengthens what already works by adding fine-grained authorization, context-aware decisions, and policy observability as a governed layer.
How It Works
Keymate differentiates itself through six core design principles:
Built on Keycloak, Extended for the Enterprise
Layer Keymate on top of your Keycloak stack. No user migration, no rewrite. You get policy-driven access, enterprise-ready features, and smoother governance.
Attribute and Risk-Aware Access Control
Make smarter access decisions using attributes, location, and risk signals. Powered by DSAC (Data Security Attribute Control) and RADAC (Risk-Adaptive Access Control), access decisions consider not just who the user is, but what they are doing, with which data, under which conditions.
Multi-Tenant IAM with Delegated Control
Support organizational isolation, scoped roles, delegated administration, and tenant control. Designed for B2B, B2B2C, and public sector use cases, each tenant gets isolated policies, user bases, and delegated admins within auditable boundaries.
Visual Policy Simulation and DSL Debugging
Simulate and trace access decisions before deployment. Identify why access is allowed or denied with dry-run tools, version diffing, and DSL tracing. Treat policies like code: diff, review, approve, and roll back.
Zero-Integration Enforcement
Secure your APIs and services at the edge or in the mesh using API gateway plugins, service mesh filters, and language SDKs. No application code changes needed.
Observability and Compliance-Ready Logging
Capture every policy evaluation, session event, and decision point using OpenTelemetry, structured audit logs, and streaming pipelines. Every decision leaves a trail; audits become a process, not a fire drill.
Example Scenario
From Role Explosion to Policy-Based Control
Before: A fintech platform manages 200+ RBAC role definitions across multiple tenants. Each new customer onboarding requires creating a new set of roles. Role audits take weeks. Access bugs appear when role boundaries are unclear.
After: By layering Keymate on their existing Keycloak deployment, the team replaces the role sprawl with scoped, context-aware policies. Roles remain as the foundation (FINANCE_ANALYST, ADMIN), but access decisions now consider tenant context, organizational scope, and risk signals. The result:
- 80% reduction in access control bugs
- Policy changes are reviewed and approved like code
- Every access decision is traceable with a "why denied?" explanation
- New tenant onboarding requires zero new role definitions
Common Misunderstandings
- "Keymate replaces Keycloak." Keymate extends Keycloak. It does not replace authentication, user federation, or SSO. Keycloak remains the identity backbone.
- "This requires a big-bang migration." Keymate supports parallel run. You can compare decisions side-by-side with your legacy setup and cut over gradually with full audit trails.
- "RBAC is dead." RBAC is foundational and remains valuable. Keymate layers context (ABAC, ReBAC, RADAC) on top of RBAC to handle the scenarios where roles alone struggle.
- "It is vendor lock-in." Keymate is built on open standards (FGA engine, OpenTelemetry, OAuth2/OIDC). Openness and portability are core principles.
Design Notes
Start small. Begin with one or two attributes (e.g., region, data_class) and one relationship (e.g., owner). Add risk conditions later as you gain observability. Use parallel run to build confidence before cutting over.