Authorization Model

Summary

Keymate's authorization framework supports multiple access control models — RBAC, ABAC, ReBAC, PBAC, DSAC, RADAC, and SBAC — within a single evaluation pipeline. Policies declare which model they use, and the platform evaluates them against the request context to produce GRANT or DENY decisions. When multiple policies apply to the same resource and scope, a configurable decision strategy determines how individual policy outcomes combine into a final decision.

Why It Exists

No single authorization model addresses every access control requirement. Role-based checks work for job-function access. Attribute conditions work for time-of-day or location restrictions. Relationship graphs work for document-level sharing. Risk signals work for fraud prevention. Real-world systems need to combine these models. Keymate's authorization model provides a unified framework where different models coexist and compose, enabling teams to apply the right model for each use case without replacing or abandoning the others.

Where It Fits in Keymate

The authorization model sits between identity (who is asking) and resources and scopes (what they are asking for). Token claims provide the identity context — roles, attributes, organizational position — that policies evaluate. The policy evaluation engine executes the evaluation. The gateway enforcement layer and the authorization service enforce the resulting decisions at their respective boundaries.

Boundaries

This page covers the multi-model architecture, decision strategies, and how models compose. It does not cover:

• Individual model details — see RBAC, ABAC, ReBAC, PBAC, DSAC, RADAC, SBAC
• Policy evaluation pipeline mechanics — see Policy Evaluation Model
• Policy authoring and lifecycle — see Policy Model
• Resource and scope definitions — see Resources & Scopes

How It Works

Supported Authorization Models

The platform supports seven authorization models, each addressing a distinct access pattern:

Model	Access Pattern	Decision Basis
RBAC	Job-function access	Role and group membership
ABAC	Context-aware restrictions	Attribute conditions on identity, resource, and environment
ReBAC	Entity-to-entity relationships	Relationship graph via the fine-grained authorization engine
PBAC	Multi-model composition	Aggregation of sub-policies with decision strategies
DSAC	Data-level security	Data classification labels
RADAC	Risk-adaptive control	Risk factor scores and thresholds
SBAC	Scope-driven access	OAuth scope grants

Each model defines its own policy structure, evaluation logic, and context requirements. The evaluation pipeline handles all models through a common interface.

Policy-to-Resource Binding

Policies bind to specific resources and scopes. A resource represents a protected entity (an API endpoint, a data record, a UI element). A scope represents an action on that resource (read, write, delete). When a request arrives, the platform identifies the target resource and scope, then retrieves all policies bound to that combination.

Decision Strategies

When multiple policies apply to the same resource-scope pair, the platform uses a decision strategy to combine their outcomes:

• Affirmative — at least one policy must grant access. If any single policy returns GRANT, the overall decision is GRANT. Use this when multiple independent policies each represent a valid path to access.
• Unanimous — all policies must grant access. If any single policy returns DENY, the overall decision is DENY. Use this when every policy represents a mandatory condition.
• Consensus — the majority of policies determines the outcome. If more policies return GRANT than DENY, the overall decision is GRANT. Use this for balanced multi-factor evaluation.

The decision strategy applies per resource-scope evaluation. Different resources can use different strategies.

Evaluation Context

The platform builds an evaluation context from multiple sources before executing policies:

• Token context — the authenticated user's identity claims, including subject identifier, issuer, and audience
• Tenant context — the active Tenant and Organization from the user's session
• Role context — the user's effective roles (realm-wide, application-specific, and department-assigned)
• Group context — the user's group memberships
• Request context — the HTTP method, path, headers, and body of the incoming request
• Risk context — risk factor scores for RADAC evaluation (device trust, location, behavior patterns)
• Custom attributes — identity attributes projected into the token or retrieved from the identity store

Policies declare which context elements they evaluate. The platform assembles the required context for each policy before execution.

Synchronous and Asynchronous Evaluation

The platform evaluates policies in two modes:

• Synchronous — the evaluation completes inline with the request. RBAC, ABAC, and ReBAC policies typically evaluate synchronously because their checks resolve quickly (membership lookup, attribute comparison, relationship graph traversal).
• Asynchronous — the evaluation executes in a separate processing context. PBAC and dynamic policies may evaluate asynchronously when they require external data lookups or complex expression evaluation.

The evaluation pipeline manages both modes transparently, returning the final decision when all policies complete.

Enforcement Points

Authorization decisions enforce at two boundaries:

• Gateway enforcement layer — evaluates permissions for requests entering the platform through the API gateway. The gateway sends a permission check request to the authorization service, receives a GRANT or DENY decision, and either forwards or rejects the request.
• Authorization service — evaluates permissions for application-level checks. Applications call the authorization service to verify access before executing operations. The authorization service supports both SDK-based requests (from application code) and plugin-based requests (from gateway plugins).

Both enforcement points use the same policy evaluation pipeline and produce consistent decisions.

Diagram

Example Scenario

Scenario

An application protects its invoice API with two policies: an RBAC policy requiring the "accountant" role, and an ABAC policy restricting access to business hours. The decision strategy is Unanimous (all must grant). A user with the "accountant" role requests access at 9 PM.

Input

• Actor: User with the "accountant" role
• Resource: Invoice API
• Action: Read invoices
• Context: RBAC policy checks role membership; ABAC policy checks time-of-day. Decision strategy: Unanimous.

Expected Outcome

• Denied — The RBAC policy grants access (user holds the "accountant" role), but the ABAC policy denies access (request occurs outside business hours). With the Unanimous strategy, the ABAC denial overrides the RBAC grant, and the overall decision is DENY.
• Why: The Unanimous strategy requires all bound policies to grant access. A single DENY from any policy produces an overall DENY.

Common Misunderstandings

• "One authorization model must cover all use cases" — No. The platform supports multiple models precisely because different use cases require different approaches. Use RBAC for role-based access, ReBAC for document sharing, ABAC for contextual restrictions, and compose them through PBAC when needed.

• "The decision strategy is global" — No. Decision strategies apply per resource-scope evaluation. Different resources can use different strategies based on their security requirements.

• "Policies evaluate in order of creation" — No. All bound policies evaluate for each request. The decision strategy combines their outcomes — the evaluation order does not affect the final decision.

warning

Choosing the wrong decision strategy can create security gaps. Affirmative allows access if any policy grants it — suitable for "any valid path" scenarios but risky if one policy is overly permissive. Unanimous ensures all conditions are met but can be overly restrictive if any policy is misconfigured to deny.

Design Notes / Best Practices

• Start with RBAC for job-function access, then layer ABAC conditions for contextual restrictions. This incremental approach avoids premature complexity.
• Use the Unanimous strategy for resources that require multiple independent security conditions (role + time + location). Use Affirmative for resources where any single authorization path suffices.
• Keep policies focused on a single concern. A policy that checks both roles and time-of-day is harder to maintain than two separate policies composed with a decision strategy.

tip

When designing authorization for a new resource, map out the access patterns first: who needs access (roles), under what conditions (attributes), and based on what relationships (graph). This mapping guides which models to apply and how to compose them.

Related Use Cases

• Combining role-based and attribute-based policies for a single resource
• Enforcing Unanimous decisions for high-security resources
• Using different authorization models for different parts of the application
• Evaluating risk factors alongside traditional role checks

Related Docs

Policy Evaluation Model

How the evaluation pipeline produces decisions

RBAC

Role-based access as the foundational model

PBAC

Multi-model composition with decision strategies

Resources & Scopes

Protected entities that policies bind to