Authorization
Keymate Authorization is centralized authorization: your access rules live as policies in one place, outside your code. It decides on every request what each user or service may do and enforces that decision in the request path, in most cases before the request reaches your application.
Every exception becomes another role
Most teams start with roles. Then the exceptions arrive: a customer may read one project only, and a contractor needs access until the end of the month. Each exception becomes a new role or another if in some service. A year later, nobody can say who may do what without reading the code. The limits of RBAC
Roles work well for coarse access. They run out when the answer depends on the specific record or on a condition at the time of the request. Keymate Authorization takes over there.
Fine-grained models, one per kind of rule
You do not pick one model for the whole company. Each policy uses the model that fits the rule, and models can be combined.
| Model | Decides by | Example |
|---|---|---|
| Role-based (RBAC) | The roles a user holds | Support agents can read tickets |
| Attribute-based (ABAC) | Attributes of the user, the resource and the moment | Doctors can open records of patients in their own ward |
| Policy-based (PBAC) | Named policies that combine conditions | Payments above 10,000 need a second approver's role |
| Relationship-based (ReBAC) | How the user is related to the resource | Members of a project team can edit the project's documents |
| Risk-adaptive (RADAC) | Risk signals at the time of the request | A login from a new device can read but not export |
| Data-scoped (DSAC) | Which records inside a resource the user may see | An account manager sees only the customers in their region |
Your existing roles keep working. Add attributes, relationships or risk only where roles stop being enough. Fine-grained authorization, in depth
One decision point for every application
Every application asks the same decision point, so a rule is written once instead of in every service. That is centralized, or externalized, authorization: you review the rule without opening application code.
Two ways to write a policy.
A visual editor, or a policy language if you prefer code. Both produce the same policy.
Policies are versioned.
Every change has an author, a reason and a diff. How changes are governed and proved, with any approval, is the job of Authorization Governance.
Decided at every request, not once at login
Many systems decide access at login and keep that answer until the session ends. Keymate decides on every request. If a right is revoked at 10:02, the request at 10:03 is denied.
Just-in-time role elevation. Because every request is decided again, a user can hold a higher privilege for one task only. It expires at a set time, and the next request is decided without it.
Enforced in the request path
Keymate enforces decisions in five places, and all five read the same policies.
| Where | What it means | Code change in your application |
|---|---|---|
| Access Gateway | A gateway in the request path checks every request | None |
| API gateway plugins (APISIX, Kong) | API authorization: your gateway asks Keymate first | None |
| Service mesh (Istio, Envoy) | Calls between services are checked inside the mesh | None |
| SDK (TypeScript, Java, .NET) | The application asks Keymate, for checks only it can make | A few lines per check |
| Event streams (Kafka) | Which applications may publish to or read each stream | None |
The other four enforcement points send their checks through the Access Gateway when one is deployed. Without it, they ask the decision point directly. You can mix them: the gateway for most applications, the SDK where a decision depends on data only the application holds. Enforcement, in depth
Bring your own decision engine
The decision point (the policy decision point, or PDP) runs inside Keymate's Keycloak build as an extension. A different decision engine can be plugged in instead. If your organization standardizes on another engine, the enforcement points and the approval, simulation and rollback steps stay the same.
How Authorization connects to the rest of the platform
- Identity and Authentication establish who is asking and how sure we are.
- Authorization decides what they may do and enforces it.
- Authorization Governance controls how policies change and keeps the evidence of what they decided: which policy decided each allow or deny, and which condition was met or missed.
Questions
What is the difference between authentication and authorization?
Authentication establishes who is asking: a person signing in, or an application presenting a token. Authorization decides what that identity may do with a specific resource, at the moment it asks. In Keymate, the Authentication module checks who is asking, and the Authorization module decides what they may do.
What is a policy decision point, and do I need one?
A policy decision point is the component that evaluates a request against your policies and answers allow or deny. You need one as soon as access rules are more than a list of roles. It gives you centralized access control: the rules stay out of application code, in one place you can review.
Which products extend Keycloak with fine-grained authorization?
Look for four parts: an identity foundation on Keycloak, a decision point for fine-grained policies, enforcement in the request path, and governance of policy changes. One common approach keeps Keycloak for identity and connects a separate authorization engine, which then has to be enforced and governed on its own. Keymate provides all four as one platform. Our comparison page sets the options side by side.
What should an authorization platform for a regulated enterprise provide?
It should run on your own infrastructure, decide every request against policies you can read, record who changed a policy and who approved it, and keep the evidence of every decision for your auditors. Those are the parts of Keymate's Authorization and Authorization Governance modules.
Do I have to change my application code?
Not for the Access Gateway, API gateway or service mesh routes: they check requests before they reach the application. The SDK is there for checks only the application can make.