Add security architecture pattern infospace
This commit is contained in:
parent
3ca891de4a
commit
5bb4b40b86
81 changed files with 6836 additions and 0 deletions
|
|
@ -0,0 +1,43 @@
|
|||
# Pattern: Role Composition
|
||||
|
||||
Status: seed
|
||||
Readiness target: RL3 production
|
||||
Primary owners: NetKingdom, flex-auth
|
||||
Genesis family: Identity and access
|
||||
|
||||
## Problem
|
||||
|
||||
Hardcoded roles become too broad, inconsistent, and difficult to review
|
||||
as products, tenants, agents, and operational tasks grow.
|
||||
|
||||
## Context
|
||||
|
||||
Use this pattern for platform roles, tenant roles, product roles,
|
||||
operator privileges, and agent scopes.
|
||||
|
||||
## Forces
|
||||
|
||||
- Roles need stable names for people and policy.
|
||||
- Permissions are resource and action specific.
|
||||
- Tenant roles differ from platform roles.
|
||||
- Agents need narrower scopes than human sponsors.
|
||||
|
||||
## Solution
|
||||
|
||||
Compose roles from named capabilities, resource scopes, actions,
|
||||
constraints, and obligations. Keep role vocabulary in a reviewable model
|
||||
that can be evaluated by flex-auth or a delegated PDP.
|
||||
|
||||
## Verification
|
||||
|
||||
- Each role maps to explicit capabilities and action sets.
|
||||
- Privileged roles are time bounded or separately approved.
|
||||
- Tenant and platform roles cannot be confused.
|
||||
- Access reviews can explain why an actor has an action.
|
||||
|
||||
## Related Patterns
|
||||
|
||||
- Policy Decision Point / Policy Enforcement Point.
|
||||
- Time-boxed Privilege Elevation.
|
||||
- Human/Agent Identity Split.
|
||||
- Object-Level Authorization Check.
|
||||
Loading…
Add table
Add a link
Reference in a new issue