Role engine

1) Authorization models

RBAC (Role-Based Access Control): the subject receives roles, roles are associated with permissions. Just manage, good for typical duties.
ABAC (Attribute-Based Access Control) - the solution depends on the attributes of the subject, resource, action and environment (time, IP, region, risk). Flexible and scalable to complex rules.
RBAC + ABAC hybrid: roles give a "basic" ability, attributes narrow it (conditions).
(Optional) ReBAC/Relationship-based: relationship graph (owner, team member, delegate), useful for documents and orgs.

2) Architecture: PDP/PEP and flows

PEP (Policy Enforcement Point): where the solution is applied (API gateway, backend method, SQL layer, UI).
PDP (Policy Decision Point): service/library that calculates'ALLOW/DENY 'by policies and attributes.
PIP (Policy Information Point): attribute sources (IdP/profile, resource metadata, risk rate, geo).
PAP (Policy Administration Point) - administrative interface/policy repository (versions, drafts, publication).

Flow: the PEP → request forms a context → the PDP pulls up the missing attributes (via PIP) → calculates the decision → PEP applies (enable/disable/cut off fields) → the audit.

3) Data model

• `subject` (user/service) с атрибутами: `tenant_id`, `roles`, `departments`, `risk_level`, `mfa_verified`, `scopes`, `claims`.
• 'resource'with type and attributes:' type ',' owner _ id ',' tenant _ id ',' classification '(public/confidential),' region ',' tags'.
• `action`: `read`, `write`, `delete`, `export`, `approve`, `impersonate` и т. п.
• `environment`: `time`, `ip`, `device`, `geo`, `auth_strength`, `business_context` (канал, тариф).

• 'roles (id, tenant_id, name, inherits []) '- support hierarchies and patterns.
• `permissions(id, resource_type, action, constraint?)`.
• `role_permissions(role_id, permission_id)`.
• 'assignments (subject_id, role_id, scope) '- scope: global/by project/by object.

• `policy(id, effect=allow|deny, target: {subject, resource, action}, condition: expr, priority, version, status)`.

4) Decision-making principles

Deny-overrides: Explicit bans prioritise permissions.
Least Privilege (PoLP): Issue minimum required access, expand through conditions.
Separation of Duties (SoD): prohibition of combinations of roles/actions (for example, "created payment" ≠ "arrested").
Context-aware: Strengthen requirements at higher risk (no MFA, suspicious IP).
Determinism: same context → same response; Log the policy version.

5) Implementation patterns

5. 1 Hybrid RBAC→ABAC (conditioning)

yaml
Declarative Policy Example
- id: doc_read_own effect: allow target: { action: read, resource. type: document, subject. roles: ["editor","owner"] }
condition: resource. owner_id == subject. id

- id: doc_read_team effect: allow target: { action: read, resource. type: document, subject. roles: ["editor","viewer"] }
condition: subject. team_id in resource. shared_team_ids

- id: doc_read_confidential_external effect: deny target: { action: read, resource. type: document }
condition: resource. classification == "confidential" and subject. tenant_id!= resource. tenant_id priority: 100 # deny high priority

5. 2 Row/Field-Level Security

At the database level: RLS policies (by 'tenant _ id', 'owner _ id').
At the API level: filter collections and mask fields if there is no'allow: read_sensitive_fields'.

5. 3 Step-up solutions

allow if action == "export" and subject. mfa_verified == true else deny

5. 4 Temporary tolerances

Grants with TTL: 'assignment. expires_at', access "windows" (during working hours of the resource region).

6) Performance and caching

Decision cache by key '(subject_hash, resource_key, action, policy_version)' with short TTL.
Edge cache of subject attributes (claims in the token) + lazy-fetch resource attributes.
Incremental invalidation: disability by events (role change, policy change, resource transfer to "confidential").
Batch checks: for lists - evaluate with a "filter" (policy-predict pushdown) so as not to pull the PDP line by line.

7) Multi-tenant

In each table - 'tenant _ id'; default policies restrict access within a lease.
Lease administrators manage only the roles/rights of their lease.
Cross-lease access - exclusively through explicit invitations/sharing with explicit deny-override.

8) Policy Administration and Lifecycle

Versioning: 'policy. version 'in the PDP response, store in audit.
Environments: draft → canary (parts of traffic/shadow mode) → prod.
Test matrix: truth tables by key roles/attributes (contract tests).
Change management: Merge requests for policies with security/compliance reviews.

9) Audit and observability

Журнал решений: `decision_id`, `subject`, `action`, `resource_ref`, `result`, `matched_policies`, `policy_version`, `attributes_digest`.
Metrics: QPS PDP, p95 latency, hit-rate cache, deny share, step-up rate, SoD incidents.
Traces: span per PDP call; correlation with API request.
Replay: the ability to "replay" historical decisions on the new version of the policy (safety check).

10) Integration with authentication and tokens

Identity - from IdP (OIDC/SAML). Tokens carry a minimum of attributes: 'sub', 'tenant', 'roles', 'auth _ time', 'amr', 'scopes'.
For ABAC, pull up the "heavy" signs from the server side (PIP) so as not to inflate the token.
Signed resource tokens (capability/invitations) - for strictly limited delegations.

11) PDP pseudo code (simplified)

python def decide(subject, resource, action, env, policies):
matched = []
effect = "deny"
Explicit DENYs with priority for p in sorted (policies, key = lambda x: x.priority, reverse = True):
if target_matches(p. target, subject, resource, action):
if eval_condition(p. condition, subject, resource, env):
matched. append(p. id)
if p. effect == "deny":
return Decision("deny", matched, p. version)
Looking for ALLOW for p in policies:
if target_matches(p. target, subject, resource, action):
if eval_condition(p. condition, subject, resource, env):
matched. append(p. id)
effect = "allow"
break return Decision(effect, matched, max_version(matched, policies))

12) Anti-patterns

"Role = page" (hundreds of small roles without a domain model).
Store policies only in code without versions/audits.
Lack of deny-override and SoD → increased fraud risk.
Hard lists' user _ id'in rules (instead of attributes/relationships).
No Data Layer Filtering (RLS) with UI filter only.
Synchronization of roles through manual scripts without events and cache disability.

13) Cases and recipes

13. 1 Field-level masking:

allow read invoice when subject. roles includes "support"
mask fields ["card_last4", "billing_email"] unless subject. role == "finance"

13. 2 Export data with MFA only:

allow export if subject. mfa_verified and env. ip in cidr("203. 0. 113. 0/24")

13. 3 SoD:

deny approve_payment if subject. performed_actions includes ("create_payment" within last 24h)

13. 4 Delegation (restricted token):

Capability token contains' resource _ id',' actions = [" read"] ',' expires _ at ',' aud '. PEP verifies signature and deadline.

14) Testing

Unit tests of policies: truth tables by major combinations.

Property-based: generation of random attributes to find "holes."

Golden-tests: fixing a set of solutions for critical endpoints.
Canary/Shadow: parallel evaluation of old and new versions of policies with logging of discrepancies.

15) Related capabilities of the "Architecture and Protocols" section

Authentication and Authorization (OIDC/OAuth2)

Consent management

Tokenization and Key Management

Observability: logs, metrics, traces

Geo-routing and localization

At Rest/In Transit Encryption

16) Architect checklist

1. Are subject roles and their hierarchies defined?
2. Is there a hybrid model: roles + conditions on attributes?
3. Implemented PDP with deny-overrides, SoD and step-up?
4. Where is PEP? (gateway, backend, database, UI) - is it uniform everywhere?
5. Are solution caches and event disability configured?
6. Are policies versioned, tested, rolled out by process?
7. Are auditing decisions, metrics, and traces enabled?
8. Multi-lease and RLS/field-masking supported?
9. Got a runbook on incidents and policy regression?

Conclusion

RBAC provides controllability, ABAC provides context and accuracy. By combining roles with attribute conditions, sharing PDP/PEP, implementing caching, auditing, and policy testing, you build authorization as a platform capability: predictable, verifiable, and scalable for product and regulatory requirements.