Authorization Policies

Authorization policies provide a rule-based layer of access control that sits alongside the role hierarchy and permissions system. Policies define explicit PERMIT or FORBID rules for specific principals performing specific actions on specific resources. They are particularly useful for fine-grained exceptions — granting or denying access that does not fit neatly into the role-based model.

Policy templates

A policy template is a reusable blueprint for creating authorization policies. Templates define:

• Source resource — the resource group, resource name, and resource ID that the template originates from
• Target principal type — USER, ROLE, or CUSTOMER
• Target principal ID — the specific principal the template targets
• Target resource — the resource group, resource name, and resource ID the policy applies to
• Target resource action — one of CREATE, READ, UPDATE, or DELETE
• Policy effect — PERMIT or FORBID

Templates allow administrators to define common access patterns once and then instantiate them as concrete policies for different users or roles without repeating the full configuration each time.

Authorization policies

An authorization policy is a concrete access rule created from a template or directly. Each policy specifies:

Field	Description
target_principal_type	The kind of principal: USER, ROLE, or CUSTOMER
target_principal_id	The specific user, role, or customer the policy applies to
target_resource_group	The three-letter business area code (e.g. CRM, HRM, FAR)
target_resource_name	The specific resource
target_resource_id	An optional specific record ID, or null for all records of that type
target_resource_action	The operation: CREATE, READ, UPDATE, or DELETE
policy_effect	PERMIT (allow) or FORBID (deny)

PERMIT and FORBID semantics

Policies use explicit effect values rather than implicit allow/deny:

• PERMIT — explicitly grants the principal permission to perform the action on the resource
• FORBID — explicitly denies the principal permission, even if other rules would allow it

When multiple policies apply to the same principal and resource, FORBID takes precedence over PERMIT. This ensures that deny rules cannot be overridden by more permissive policies elsewhere.

Enforcement

Authorization policies are enforced whenever a protected resource is created, changed, or removed. If an applicable FORBID policy exists for the current user and action, the operation is rejected.

Policy assignments

Policies are linked to principals through two assignment types:

User policy assignments

User policy assignments link a policy directly to a specific user. This is used when an individual user needs an exception — either an additional grant or a specific restriction — that does not apply to their role as a whole.

Role policy assignments

Role policy assignments link a policy to a role. All users who hold that role are subject to the policy. This is the more common pattern, since most access rules apply to everyone in a given role.

How policies relate to other access control layers

Authorization policies are one of several layers in Raytio's defence-in-depth access control:

• Relationship-based access handles broad access patterns such as tenant isolation, ownership, sharing, and membership.
• Permissions define what operations a role can perform on a resource group.
• Policies add targeted PERMIT/FORBID rules for specific principals and resources, handling exceptions and fine-grained control.
• Menus control what the user sees in the UI.

note

Authorization policies provide targeted overrides, while relationship-based access provides broad ownership, sharing, and membership checks.

When to use policies vs other mechanisms

Scenario	Recommended mechanism
A role should have access to an entire business area	Permissions (role–permission assignment)
A specific user needs access to a single record	Authorization policy (user policy assignment with resource ID)
A role should be denied a specific action on a specific resource	Authorization policy (role policy assignment with FORBID)
Access depends on the relationship between user and record	Relationship-based access
A user should not see a menu item	Role menus (menu entry overrides)