Skip to main content

Policy-Based Access Control (PBAC)

Policy-Based Access Control (PBAC) resolves authorization by evaluating logical policies against the context of each request. Instead of asking "what role does this user have" or "what relationship connects the subject to the resource," PBAC asks "do the attributes of this request satisfy the rules expressed in this policy."

SecureAuth Connect's PBAC is delivered through SecureAuth policies, which you author in Rego or the visual policy editor and attach at workspace, application, scope, or API request level. PBAC also covers Attribute-Based Access Control (ABAC): the same policy engine evaluates user, client, and request attributes.

How PBAC works on SecureAuth​

A policy is a set of logical rules that returns an allow or deny decision. At evaluation time, SecureAuth passes the policy a snapshot of the request and the identity, including:

  • Identity attributes, such as user groups, roles, and identity pool schema fields.
  • Token and authentication context claims, such as sub, amr, acr, and any custom claims.
  • Request context, such as scopes, headers, client metadata, and dynamic scope resource identifiers.
  • External data, either fetched at evaluation time from a Rego policy or injected into token claims beforehand by a SecureAuth Extension.

The policy combines these inputs with logical rules and returns allow or deny.

Example​

A customer-banking application needs two rules on its money-transfer API:

  • Transfers over $10,000 require that the user has completed MFA in the current session.
  • Users flagged as high-risk cannot initiate transfers from outside their registered country.

A PBAC policy expresses both rules in one place:

  • Read the amount from the request and the amr and risk_flag claims from the access token.
  • If amount > 10000 and the amr claim does not include an MFA factor, deny.
  • If risk_flag is high and the request header X-Country does not match the user's registered_country attribute, deny.
  • Otherwise, allow.

The same policy can attach to the token-issue flow, so the token is only minted when the rules pass, or to the API gateway, so every request is re-evaluated against the current context.

When to use PBAC​

Reach for PBAC when the decision depends on dynamic context, not a fixed role or a stored relationship:

  • Time, location, device, or network-based access rules.
  • Risk-based or step-up authentication decisions.
  • Rules that combine multiple attribute sources (identity, token, request, external feed).
  • ABAC patterns, including fine-grained attribute checks inside a larger policy.
  • Layering contextual conditions on top of an existing RBAC or ReBAC model.

For role-driven coarse access, see Role-Based Access Control (RBAC). For graph-driven object-level access, see Relationship-Based Access Control (ReBAC) and Fine-Grained Access (FGA).

PBAC on SecureAuth​

SecureAuth policies run on a single evaluation engine regardless of how they are authored. You can:

Because the same engine runs at token issuance and at the gateway, one policy can cover both in-platform enforcement and external enforcement without duplicating logic.

Combining PBAC with other models​

PBAC is often the glue over other models. A common pattern:

  • RBAC for the coarse cut: does the role allow the action at all.
  • ReBAC or FGA for object-level access: is this specific record owned by or shared with this user.
  • PBAC for contextual overrides: require MFA at high-risk moments, or block when the request context looks wrong.

SecureAuth evaluates all three through the same policy surface, so one attached policy can combine role, relationship, and context checks.

See also​