AuthZen TIA Plugin

Use Cases#

The AuthZen TIA plugin is useful when scope issuance decisions should be made by an external Policy Decision Point (PDP) rather than by rules configured within the Curity Identity Server itself. This allows organizations to centralize their authorization logic in a dedicated PDP, for example Open Policy Agent (OPA) or any other AuthZen-compliant engine, and have the Curity Identity Server enforce those decisions during token issuance.

Typical use cases include:

• Fine-grained scope authorization based on user attributes, resource metadata, or external entitlements stored in the PDP.
• Reusing existing authorization policies across multiple systems by centralizing them in a dedicated PDP.
• Auditing and tracing scope decisions in the PDP independently of the token issuance flow.

Process#

When a token is about to be issued, the AuthZen TIA plugin collects all requested scopes and sends them as a batch evaluation request to the configured AuthZen Access Evaluations endpoint. The PDP responds with an allow or deny decision for each scope. The plugin translates each response into a TIA decision that the Token Issuance Authorizer framework then uses to determine which scopes are included in the issued token.

The evaluation request carries:

• subject — the identity of the user being authorized
• context — contextual information about the token issuance request (e.g. grant type, client ID)
• evaluations — one entry per requested scope, each describing the resource and action being requested
• options — evaluation semantics controlling how the PDP processes the batch

All scopes are evaluated regardless of the outcome of the others (execute_all).

Request Context Attributes#

The context object in the evaluation request contains the following attributes:

Scope-to-Resource Mapping#

The plugin maps each OAuth scope to an AuthZen resource and action using the following rules based on hierarchical scope notation (e.g. resource:segment:action). For simple (non-hierarchical) scopes (e.g. order), resource.type is set to the scope name, action.name is set to the configured default-action, and no path is included.

The resource.id is always set to * to indicate that the evaluation applies to all instances of the resource type.

Example Evaluation Request#

The following example shows a request for three scopes — a simple scope, a two-segment scope, and a deep hierarchical scope:

{
  "subject": {
    "type": "user",
    "id": "john.doe"
  },
  "context": {
    "phase": "scope_evaluation",
    "grant_type": "authorization_code",
    "client_id": "my-client",
    "client_auth_method": "client_secret_basic"
  },
  "evaluations": [
    {
      "resource": {
        "type": "test",
        "id": "*"
      },
      "action": {
        "name": "read"
      },
      "context": {
        "scope": "test:read"
      }
    },
    {
      "resource": {
        "type": "order",
        "id": "*"
      },
      "action": {
        "name": "access"
      },
      "context": {
        "scope": "order"
      }
    },
    {
      "resource": {
        "type": "order",
        "id": "*",
        "properties": {
          "path": ["customer_orders", "new", "local"]
        }
      },
      "action": {
        "name": "read"
      },
      "context": {
        "scope": "order:customer_orders:new:local:read"
      }
    }
  ],
  "options": {
    "evaluations_semantic": "execute_all"
  }
}

Configuration#

evaluations-url#

The full URL of the AuthZen Access Evaluations endpoint on the PDP, for example https://pdp.example.com/access/v1/evaluations. The plugin sends a POST request to this URL for each token issuance event.

http-client#

A reference to an HTTP client facility used to connect to the PDP.

subject-type#

The value placed in subject.type in every evaluation request. Defaults to user.

default-action#

The action name to use when a scope is non-hierarchical (e.g. order) or when the last segment of a hierarchical scope does not appear in the available-actions list.

available-actions#

A list of action names that are recognized as the last segment of a hierarchical scope. When the last segment of a scope matches one of these values, it is used as action.name in the evaluation. When it does not match, the default-action is used instead.

The default values are read, write, update, and delete.

wrap-in-opa-input#

When set to true, the entire evaluation request body is wrapped under an input key before being sent. This is required for OPA-based PDPs, which expect the request document to be placed under input:

{
  "input": {
    "subject": { ... },
    "context": { ... },
    "evaluations": [ ... ],
    "options": { ... }
  }
}