·7 сценариев
topologyconceptsPublic
RBAC Implementation Patterns
RBAC implementation patterns: API Gateway enforces authz via dedicated AuthZ service backed by Redis cache and auth_db (users/roles/permissions). OPA sidecar overlays ABAC. Admin role mutations write to auth_db, append to audit_log, publish invalidation events through pub/sub to all authz pods which DEL the user's cache key. Three scenarios: cached gateway check (hot path), hierarchical role inheritance with recursive CTE expansion on cache miss, and role revoke with sub-second cache invalidation contrasted against JWT-claims staleness.
Key · @kuzminykh_igor_b3550a9b0 звёзд
1 просмотр
только что · последнее обновление
RBAC implementation patterns: roles, sessions, hierarchy, and separation of duty
RBAC connects users to roles and roles to permissions. Production implementations preserve role activation, hierarchy, separation of duty, tenant scope, administrative control, and revocation semantics instead of collapsing policy into ad hoc role strings.
Security invariants
- RBAC-C1: Core RBAC contains user-role and permission-role relations, with users receiving permissions through roles rather than ad hoc direct grants.
- RBAC-C2: RBAC sessions activate a subset of assigned roles, enabling least privilege for a particular interaction.
- RBAC-C3: Role hierarchies are reviewed partial-order relations whose inheritance must not introduce cycles or unintended authority.
- RBAC-C4: Static separation of duty constrains role assignment, while dynamic separation of duty constrains simultaneous role activation.
- RBAC-C5: Multi-tenant RBAC scopes assignments and permissions to the tenant rather than treating role names as global capabilities.
- RBAC-C6: Revocation, cached decision freshness, and role administration are explicit authorization operations with audit and delegated-administration controls.
Trust-boundary map
| Component | Responsibility |
|---|---|
user | User |
session | Activated Role Session |
enforcement | Authorization Enforcement |
role-service | Role Assignment Service |
permission-store | Role-Permission Store |
hierarchy-store | Role Hierarchy |
sod-engine | Separation-of-Duty Constraints |
tenant-store | Tenant Scope |
audit-log | Administrative and Decision Audit |
role-admin | Constrained Role Administrator |
Topology edges represent authenticated or otherwise explicit communication paths. Responses reuse those physical paths in reverse; no response-only or bypass edges are added.
Executable scenarios
activate-least-role-set — Activate the least role set
A session activates only the subset of assigned roles needed for the current task, reducing ambient authority.
role-hierarchy — Evaluate role hierarchy as a partial order
Senior roles inherit authorized permissions according to a reviewed hierarchy; cycles and accidental privilege amplification are rejected.
static-separation-of-duty — Static separation of duty
Conflicting roles cannot be assigned to the same user when that assignment would violate the organizational constraint.
dynamic-separation-of-duty — Dynamic separation of duty
A user may hold multiple roles but cannot activate a conflicting combination in one session or transaction.
tenant-scoped-role — Scope role assignments by tenant
The label admin is not globally meaningful; assignment and permission resolution include tenant or organization identity.
revocation-and-cache — Propagate revocation to decision caches
Removing a role assignment advances a policy version and invalidates active sessions or cached allows within a defined bound.
constrained-administration — Constrain role administration
Policy administration is itself authorized and audited; a help-desk operator cannot grant a role above its delegated scope.
Operational and failure rules
- Every rejection path fails closed at the component that owns the decision; infrastructure failure is never converted into authentication, authorization, or integrity success.
- Retries preserve stable transaction identity, replay detection, bounded freshness, and audit context. A retry does not erase a prior success or compromise signal.
- Concurrent validation branches are independent checks. Completion requires every mandatory branch, and no check substitutes for another.
- Logs contain decision metadata and stable identifiers, not credentials, bearer tokens, cryptographic keys, or sensitive payloads.
Related concepts
[CONCEPT]authz-models [CONCEPT]zero-trust [CONCEPT]api-security [CONCEPT]authn-modelsAuthoritative sources
Комментарии · 0
Комментариев пока нет. Будьте первым.
Калькулятор ёмкости
Введите числа или выберите пресет