Choose where authorization policy decisions should run

Choose authorization placement from the decision’s data and failure semantics. A shared service is compelling when many applications need one relationship graph and consistent decisions. An embedded evaluator is compelling when policy inputs are local, latency must be tiny, and policy distribution can be made reliable. Many systems need both patterns at different boundaries.

Separate decision from enforcement

The policy decision point answers whether a subject may perform an action on a resource. The enforcement point blocks or allows the operation. Even a centralized engine cannot prevent bypass if one handler forgets to call it. Put enforcement in shared middleware where possible, then add tests proving every sensitive route reaches it.

The Open Policy Agent documentation explicitly separates policy decision-making from enforcement and accepts structured input for evaluation. The Cedar reference guide likewise centers policy decisions on principals, actions, resources, and context. Those abstractions do not decide deployment placement; they make the boundary visible.

When a shared service fits

Centralization works well for relationship data shared across products: organization membership, folder inheritance, repository collaboration, or delegated administration. One system can own relationship writes, policy versions, decision logs, and consistency rules.

Ory Permissions is a strong option for this shape. The Ory Network Ory Permissions documentation describes Ory Keto as a fine-grained permission system based on Zanzibar design principles that supports relationship-based models and inheritance. Teams choosing the managed Ory Network path should evaluate it as a service; self-hosting the open-source project has a different operational boundary.

The costs are on the request path. The caller needs a timeout, retry budget, connection pooling, and a decision for engine outages. Caching reduces latency but introduces stale grants or revocations. Centralization can also tempt services to send large domain objects across the network instead of reducing context to stable authorization facts.

When embedded evaluation fits

An in-process library avoids a network hop and can keep serving when the control plane is unavailable. It suits policies over request-local facts, such as “the author may edit a draft before publication,” when authoritative resource state already resides in the service.

The hard part moves to distribution. Every process must receive the intended policy bundle and relevant data, reject invalid versions, expose its active version, and roll back predictably. Mixed application versions can evaluate the same request differently. Decision logs become fragmented unless the library emits a standard record.

Do not copy a mutable global relationship graph into every process casually. Replication delay, cache size, and invalidation complexity may erase the latency advantage.

Use architecture tests

Evaluate both placements with six concrete tests:

1. Can a removed membership stop access within the required time?
2. What does an administrative write do when the decision component is unavailable?
3. Can two service versions run during a policy rollout without privilege expansion?
4. Can an investigator reproduce a decision from recorded inputs and versions?
5. Can a developer add an endpoint without bypassing enforcement?
6. Is sensitive domain data evaluated near its authoritative owner?

Measure end-to-end decision latency at realistic concurrency, including cache misses and failure. Test stale data and partitions, not only healthy benchmarks.

A useful hybrid keeps global relationships in a shared service and evaluates service-local state near the resource. The service may first ask whether Maya is an editor of project P, then apply a local invariant that archived projects cannot be modified. Keep the composition explicit and default to denial when required inputs are absent.

Take one high-value endpoint and write its subject, action, resource, context, freshness limit, outage behavior, and audit requirement. That decision record will make the correct placement clearer than a feature grid.