Where to resolve resource-owner when checking entitlements/authZ

Question

At the company I work for; we're planning a custom entitlement service (using Open Policy Agent as the policy engine) for fine-grained authZ decisioning.

The high-level architecture looks like the following:

Basically entitlements-enabled microservices pass identity (JWT subject), operation (GET/POST/PUT/PATCH/DELETE), and resource (/thing/12345) to the entitlement service to get an authZ decision. The decision is just an boolean allow/deny response. Entitlements persists information about users, groups and roles (that it receives asynchronously from IDP and other systems), so it is able to look up this information from it's local data source and pass it through to OPA (using the overloaded input pattern). Entitlements/OPA is just running as a stand-alone service - we're not running OPA as a side-car or anything fancy like that...

The problem we're trying to solve is that for most routes the resource-owner is not part of the resource path, but we still need the resource-owner to be able to make an authZ decision.

I can think of 3 ways to get the resource owner through to entitlements. I'm looking to get some advice about what would be the best approach.

1. Include resource owner information in all resource paths e.g. /user/{id}/thing/12345. TBH not sure how viable this approach would be in our ecosystem, so this would probably be my lowest preference.
2. Entitlements-enabled services need to look up the resource-owner (for a given resource) and pass this through to entitlements (along with identity, operation, and resource).
3. Sync resource-identifiers (mapped to resource owners) through to entitlements as resources are created, so that entitlements-enabled services can subsequently just pass identity, operation, and resource to get authZ decision.

Answer 1

This usually boils down to requirements around memory consumption and the frequency of which the data is expected to change. To try and summarize:

Lookup of permission data with request or in-policy

Pros:

• Data is known to be up-to-date at the time of the decision.

Cons:

• Extra lookups all add to the total request time. In distributed environments like microservice architectures, the impact is potentially big.

Keeping permission data in memory

Pros:

• As lookups are done from memory they're normally be very fast.

Cons:

• Data only as up to date as the time of the last sync.
• Unless it's feasible to push all data with each update, custom logic for only syncing diffs/deltas needs to be implemented and maintained. The complexity of this largely depends on the underlying data source.
• Depending on the size of the data, may require a lot of memory - especially so if distributed among many OPA instances as they'll all be carrying a copy of the data.