Why Keymate? How We Got Here

Why Keymate? How We Got Here

Keycloak was just the beginning. Meet Keymate.

Estimated read: 6–7 minutes

TL;DR

After years building identity and authorization often on Keycloak we kept hitting the same wall: RBAC role explosion, multi-tenancy & delegation gaps, and invisible policy decisions. "Rip-and-replace" is risky; "do nothing" is riskier. Keymate emerged from a simple idea: Don't replace your IAM. layer intelligence and visibility on top of it, run in parallel, and make access explainable and governable.

📧 Following this series? Get the next chapter when it drops → insights on modern IAM and authorization patterns.

A few questions before we begin

• Can your IAM tell you who got access, when, in what context, and why without a war room?

• When a request is denied, can you answer "why denied?" in seconds with evidence?

• Can you separate tenants cleanly and delegate administration without spreadsheets?

• Can you version, approve, and roll back policies like real software artifacts?

• Can you enforce at the edge (API Gateway/Service Mesh) without touching app code?

• Could you run next to your legacy IAM in parallel, compare decisions, and cut over gradually?

• Can your IAM surface anomalies or explain access in plain English — AI-assisted, human-governed — without turning governance into a black box?

If any of those are a "not really," you're in good company.

The view from the trenches

We've spent years writing identity and authorization first homegrown, then on Keycloak across our own products and client projects, wearing different hats. We've seen Keycloak lift heavy loads, and we've also seen the same missing pieces repeat in real enterprise environments.

We didn't want "another IAM". We wanted a governed, explainable authorization layer that sits on top of what you already have.

We learned a hard truth: confidence in authorization doesn’t come from more roles; it comes from context, lifecycle, and visibility.

The three stubborn problems

1. RBAC role explosion & context blindness

Roles multiply as systems and use-cases grow. The more roles you add, the fuzzier your intent becomes. Without first-class context attributes, relationships, risk you're stuck between over-granting or drowning in exceptions.

📊 At one recent scale: ~120 tenants, 9 apps, ~650 roles (+35% YoY) the sprawl became the work.

2. Multi-tenancy & delegated admin gaps

B2B/B2B2C/G2C topologies require strict tenant isolation, organizational hierarchy, and clean delegation. Without a crisp model, operations slide back to ad-hoc emails and manual approvals brittle, slow, and audit-unfriendly.

3. Policy lifecycle & invisibility

Policies should behave like software: versioned, reviewed, approved, tested, rolled back. In practice, approvals are informal, diffs get lost, and when access is denied there's no explainable trace to show which rule fired. If decisions aren't observable, risk management turns into guesswork.

Policies should be treated like code — think “GitHub for authorization”: diffs, pull requests, reviews, and rollbacks.

Rip-and-replace or do-nothing? Neither.

• Rip-and-replace: promises a clean slate after months of risk, rewrites, and disruption.
• Do-nothing: feels safe today, but compliance pressure, audit costs, and operational drag compound tomorrow.

Technical debt rarely disappears; it usually migrates.

👉 We needed a third way: augment, don't replace.

What we decided to optimize for (Ends ↔ Means)

We framed our goal (Ends) and our approach (Means) in plain terms:

• Ends: Enterprise-grade access that is fine-grained, contextual, explainable, and auditable.
• Means: A governed authorization layer you can run in parallel on top of the IAM you already use, with a real policy lifecycle and observable decisions.

Non-negotiable Principles:

1. Layer, don't replace. Strengthen what works; avoid risky rewrites.
2. Context is first-class. Who, related to what, under which risk, accessing which data.
3. Policy = software. Version, diff, review, approve, test, roll back.
4. Explainability. Answer "why denied?" / "why allowed?" with evidence.
5. AI-assisted, human-governed insight. Use AI to surface anomalies and recommend policy improvements — while humans stay in the loop for trust, auditability, and accountability.
6. Observability. Every decision leaves a trail; audits become a process, not a fire drill.
7. Edge enforcement when possible. Push checks to gateways/meshes to minimize app changes.
8. Parallel run. Compare legacy vs. new decisions, spot mismatches, and cut over gradually with confidence.

So… why Keymate?

Because we didn't need another identity provider. We needed a thinking, visible, governable authorization layer that lets enterprises:

• Keep the identity stack that already authenticates users
• Add fine-grained, contextual control where RBAC alone struggles
• Model tenants and delegation without spreadsheets
• Make policy lifecycle real (version/approval/rollback/simulation)
• Explain decisions to auditors and engineers
• Observe everything
• Adopt safely via parallel run no big-bang cutover

What Keymate is not

• ❌ Not a "throw-everything-away" migration project.
• ❌ Not a black box. If your policies are unclear, Keymate makes that visible so you can fix it.
• ❌ Not vendor lock-in. Openness and portability matter.
• ❌ Not “AI magic.” We believe in AI-assisted, human-verified governance — not black-box automation.

Where this series goes next

This is the first chapter in a longer journey. Next up:

1. The Limits of RBAC — why role explosion is inevitable at scale.
2. Multi-Tenancy & Delegation — modeling reality without manual glue.
3. Policy Lifecycle — treating policy as code, not configuration.
4. Observability & "Why Denied?" — evidence, not folklore.