Why Keymate is built this way

Only the developers who wrote an access rule in code can read it, so nobody else can prove what it allows. A typical check reads "if the user has the role finance-approver and the amount is below the limit, allow". Each check is reasonable on the day it is written. Five years and twenty services later, the same rule exists in three languages, and three teams maintain it. Nobody can answer "who can approve a payment above 50,000?" without reading all of them.

When an auditor asks that question, three things are missing:

• There is no list to show.

  The rules are spread across codebases, so the question goes to developers, and the answer is their reading of the code on that day.

• The change was never approved as an access change.

  A new condition ships inside a release; the release approval covers the feature, not the permission hidden in it.

• Nothing recorded the decision.

  Application logs record requests and errors. Few record which rule allowed or denied a request, and on what condition.

The usual workaround is more roles. A new role for every exception keeps the code shorter but moves the problem into the identity system. Hundreds of roles pile up, and nobody can say any more what each one was for. The limits of RBAC explains why.

Taking access rules out of the application splits the work into three jobs. Keymate is an authorization platform with a separate part for each:

• Decide.

  A policy decision point (PDP) evaluates each request against your policies and answers allow or deny. Every application asks the same one, as Authorization describes.

• Enforce.

  A policy enforcement point (PEP) in the request path acts on the answer: the Access Gateway, an API gateway plugin, a service mesh filter, an SDK call or an event-stream check. Only the SDK needs code in the application.

• Govern.

  Authorization Governance controls how a policy changes: draft, simulate against past decisions, publish, roll back, and you can require an approver before publishing. Every decision is recorded with the policy version behind it.

Keymate runs identity and authorization in one platform because every authorization decision depends on identity: who the user is, which organization they act for and how they signed in. When identity and authorization are separate products, that context crosses a product boundary on every request. Each side also has its own console, release cycle and audit log. In Keymate, the user's active organization and the result of a step-up check travel in every token. Policies read them directly, and the decision record names the same user and organization the Identity module holds. A decision engine bought on its own is one more product to connect, govern and depend on.

The identity foundation is Keycloak, the open-source IAM project many enterprises already run. Keycloak is production ready on its own. What Keymate adds as a product are the Keycloak enterprise features that teams otherwise build around it:

• Keymate's own Keycloak build, hardened, with a signed supply chain (Architecture);
• nested organizations, with administration each customer runs for itself (Identity);
• authorization decided and enforced on every request (Authorization);
• simulation, rollback and evidence for every policy change (Authorization Governance).

If you run Keycloak today, your realms move into Keymate with Keycloak's realm export and import; Keymate vs Keycloak compares the two module by module. Our engineers contribute to Keycloak upstream, and the public record lists each change.

The whole platform is self-hosted: it runs on Kubernetes, wherever your Kubernetes runs, including air-gapped networks (Enterprise), and the product reports nothing back to us. Architecture shows where each component runs.

These are the limits to check before you shortlist Keymate.

• Not a privileged-access product.

  Privileged access management (PAM) products vault administrator and machine credentials, and broker and record their sessions. Keymate does none of this and works next to a PAM product. Its just-in-time role elevation in Authorization is not a credential vault. It covers application privileges a user requests for a task, which end within hours.

• Not a classic identity governance suite.

  Classic identity governance and administration suites run certification campaigns, segregation-of-duties rules and access request catalogs. If your organization needs a full governance suite, Keymate is not one, but it works next to one: the suite governs who holds which entitlement, and Keymate decides and records what each request may do. Identity Governance covers joiners, movers and leavers driven by HR events today; access reviews are on the roadmap.

• Not a consumer-identity growth suite.

  Consumer identity and access management (CIAM) products are built for the public sign-up funnel: registration conversion, progressive profiling, marketing consent and identity document checks. Keymate is built for employees, and for the customers and partners of a business, each organization with its own administrators.

• Not different at single sign-on and multi-factor authentication.

  Every identity product has to do them well, and Keymate does them on Keycloak (Authentication) with no claim of difference. What it adds is that Authorization reads how the user signed in, including a step-up check, on every request.

• Not open source.

  Keymate has a free edition under its own license, Community, with every module for up to 100 registered users. Above 100 users, every module is paid, priced per user and per module. Keycloak, the identity foundation it is built on, is open source.