Five policy enforcement points, one set of policies

A protected request goes through five steps between the client and your application. The diagram shows them for the Access Gateway, the usual way in. The other four enforcement points send their checks through the Access Gateway when one is deployed. Otherwise they ask the decision point directly.

1. The request arrives with a token. A user or a service signs in through Keymate's Keycloak build, and the token they receive says who they are, which organization is active and how strongly they signed in. Their requests for the application are routed through the Access Gateway, which sits in the application's request path.
2. The token is checked. The gateway verifies the token and, when the token is bound to a key, the DPoP proof that comes with the request. Services behind the gateway receive a normal token and need no change to support DPoP.
3. The gateway asks the decision point. It passes who is asking, the action, the resource and the context of the request.
4. The decision point answers allow or deny. It evaluates the policies that apply, built from roles, attributes, relationships and risk. It records which policy decided, which condition was met or missed, and the policy version in force. The models a policy can use are in the fine-grained authorization deep dive.
5. Allowed requests are forwarded; denied requests stop at the gateway. The application receives only requests that passed.

Sign-in happens once, but steps 2 to 5 run again for every request. If a right is revoked at 10:02, the request at 10:03 is denied.

A policy decision point (PDP) evaluates a request against your policies and answers allow or deny. A policy enforcement point (PEP) sits in the request path and acts on the answer. Keeping the two apart puts the policies in one place, where they cover many applications.

A zero trust policy enforcement point checks every request on its own, whatever network it came from. It never trusts a caller just because it is inside the perimeter. Keymate's enforcement points work that way. On a protected route, service or topic, a call from a service inside your cluster is checked against the same policies as a call from the internet. The PDP and PEP architecture page shows how the decision point, the enforcement points and the audit pipeline fit together.

All five ask the same decision point. What changes is where the check runs and what your team has to set up:

Access Gateway

The Access Gateway is Keymate's own gateway, built on Apache APISIX and Envoy, placed in the request path of an application or a group of applications. It checks every request and forwards only the ones the decision point allows, so the application never sees a denied request.

API gateway plugins: APISIX and Kong

If your APIs already sit behind Apache APISIX or Kong, Keymate adds a plugin to that gateway instead of placing a second one in front. The gateway asks Keymate before forwarding each call. No API needs its own authorization code. In this Keycloak API gateway integration, Keymate issues the token and decides whether the call goes through.

Service mesh: Istio and Envoy

With Istio or Envoy, Keymate checks calls between services inside the mesh. A service that is never exposed to the outside still cannot be called by a service without the right to call it. When Keymate's Keycloak build issues the tokens and Istio carries the calls, the rule for which service may call which moves out of each service's code and into Keymate's policies.

A service needs no code change, as long as it runs in the mesh.

SDK: TypeScript, Java and .NET

The SDK is for decisions that depend on data only the application holds, such as the amount on an invoice it has just loaded. Its check goes through the Access Gateway when one is deployed, or straight to the decision point when not. The application then acts on the answer. The decision is recorded as it would be at the gateway, with the policy that decided and the version in force.

Event streams: Kafka

Event-stream authorization decides which application may publish to, or read from, which stream of events. Keymate does it for Kafka, using the same policies as web requests.

You can use more than one enforcement point, chosen per application by where its traffic already flows.

Authorization for microservices usually combines two enforcement points: the Access Gateway or an API gateway plugin at the edge, and the service mesh between services. The SDK is added only where a rule needs data that no gateway can see.

A policy is written once in the admin console and applies wherever the request is checked. A rule that denies a call at the gateway also denies it in the mesh or in an SDK check. Every decision is recorded with the policy version in force. If you require an approver, a policy change is approved once in Authorization Governance, not once per enforcement point.

Keycloak's own policy enforcer is a library inside a Java application. It intercepts that application's requests and asks Keycloak Authorization Services for a decision. Keymate keeps Authorization Services available and moves enforcement out of the application. The Access Gateway, the API gateway plugins and the service mesh check requests for applications in any language, with no library to add.

If your applications are Java services and your rules fit Keycloak's resources, scopes and policies, the policy enforcer may be all you need. How Keycloak decides permit or deny is explained in Keycloak Authorization Services.