Skip to main content

Resource Resolution & Routing Metadata

Summary​

Resource resolution is the mechanism by which the Access Gateway determines the target resources for a permission check when the caller does not provide them explicitly. Instead of requiring every enforcer to know the exact resource names and scopes, the gateway derives this information from the request URI and HTTP method using access rules.

This enables a URI-driven authorization model where API routes map directly to protected resources.

Why It Exists​

In many integration scenarios, the caller knows where it is sending a request (the URI and method) but not what protected resource that endpoint maps to. This is especially true for:

  • API Gateway plugins that intercept requests and need to check permissions before forwarding.
  • Generic SDK integrations where the application code delegates authorization entirely to the gateway.
  • Microservice-to-microservice calls where the caller should not need to maintain a resource catalog.

Resource resolution bridges this gap — the gateway owns the mapping between routes and resources.

Where It Fits in Keymate​

Resource resolution is a specialized capability of the Access Gateway, triggered when the enforcer provides the target URI and HTTP method (via Keymate-Target-URI and Keymate-Target-Method headers) instead of specifying resources explicitly in the request body.

Boundaries​

What resource resolution covers:

  • Mapping request URI and HTTP method to resource names and scopes
  • Providing the resolved resources to the permission check flow

What resource resolution does not cover:

How It Works​

The Access Gateway supports two ways to specify what resources to check:

  • Explicit resources — the enforcer specifies the resources and scopes directly in the request body. This is the typical pattern for SDK integrations where the application knows which resources to check.
  • Resource resolution — the enforcer provides the target URI and HTTP method via headers, and the gateway resolves the corresponding resources from access rules. This is the typical pattern for API Gateway plugins and service mesh integrations.

Example Scenario​

Scenario​

An API gateway plugin intercepts a GET request to /api/v1/employees/42 and calls the Access Gateway to check whether the caller has permission. The plugin does not know which protected resource maps to this endpoint.

Input​

  • Actor: Authenticated user with a valid access token (Bearer or DPoP)
  • Resource: Not specified (empty body)
  • Action: GET request to /api/v1/employees/42
  • Context: Keymate-Target-URI: /api/v1/employees/42, Keymate-Target-Method: GET

Expected Outcome​

Common Misunderstandings​

  • "Resource resolution is a fallback for malformed requests." — No. It is an explicit operation mode for enforcers that know the target URI and method but not the resource name.
  • "The Keymate-Target-URI must match the actual request URI." — The Keymate-Target-URI is a logical value provided by the enforcer. It represents the downstream endpoint, not the Access Gateway's own endpoint.

Design Notes / Best Practices​

  • Use resource resolution for gateway plugin and service mesh integrations where the caller naturally knows the URI and method but not the resource name.
  • Use explicit resources in the body for application-level calls (SDKs, Admin Console) where the caller knows exactly which resources to check.
tip

For application-level calls, provide resources explicitly in the request body. Reserve resource resolution for gateway plugin and service mesh integrations where the caller delegates resource mapping to the gateway.

Runtime Evaluation Model

Access rules that drive token exchange and resource resolution.

Enforcement Pipeline

Request processing pipeline where resource resolution operates.

Overview

Access Gateway capabilities and API endpoints.

Keymate Authorization Decision Provider

Fine-grained permission evaluation engine that evaluates the resolved resources.