generated from coulomb/repo-seed
79 lines
2.6 KiB
Markdown
79 lines
2.6 KiB
Markdown
# Pattern: Delegated Authorization
|
|
|
|
Status: reviewed
|
|
Readiness target: RL3 production
|
|
Primary owners: flex-auth, NetKingdom
|
|
|
|
## Problem
|
|
|
|
Identity providers and application code should not become the scattered
|
|
home for every tenant, resource, and object-level authorization rule.
|
|
|
|
## Context
|
|
|
|
Use this pattern for protected systems that need consistent decisions
|
|
for tenant-scoped resources, privileged operations, object storage,
|
|
agent access, and application APIs.
|
|
|
|
## Forces
|
|
|
|
- Applications need local enforcement, but policy needs central shape.
|
|
- Tenant, resource, action, assurance, and context must travel together.
|
|
- Some decisions can be delegated to PDP runtimes such as Topaz.
|
|
- Deny reasons and obligations need to be auditable.
|
|
|
|
## Solution
|
|
|
|
Use flex-auth as the canonical authorization boundary. Callers submit a
|
|
standard decision request; flex-auth evaluates directly or delegates to
|
|
Topaz; applications enforce the returned allow/deny, obligations, and
|
|
audit metadata at the boundary.
|
|
|
|
## Implementation Sketch
|
|
|
|
1. Register protected systems and resource/action vocabulary.
|
|
2. Define the decision envelope and CARING descriptors.
|
|
3. Add policy packages with tenant/platform separation.
|
|
4. Delegate to Topaz where ReBAC or policy runtime support is useful.
|
|
5. Return stable allow/deny, reason, obligation, and audit fields.
|
|
6. Require applications to enforce decisions before resource access.
|
|
|
|
## Failure Modes
|
|
|
|
| Failure | Mitigation |
|
|
| --- | --- |
|
|
| App ignores deny obligations | add conformance tests at enforcement points |
|
|
| Policies mix platform and tenant authority | separate policy packages and review paths |
|
|
| Decision context omits tenant | fail closed |
|
|
| PDP outage becomes implicit allow | fail closed except documented emergency flows |
|
|
|
|
## Related Capabilities
|
|
|
|
- Authorization and access control.
|
|
- Tenant isolation.
|
|
- Application and API security.
|
|
- Observability, detection, and audit.
|
|
|
|
## Maturity
|
|
|
|
Reviewed. This is a core NetKingdom boundary and should become
|
|
canonical once flex-auth conformance fixtures are stable.
|
|
|
|
## Verification
|
|
|
|
- Decision envelopes include actor, tenant, resource, action, context,
|
|
obligations, reason, and audit id.
|
|
- Enforcement points deny when flex-auth denies or is unavailable.
|
|
- Topaz delegation is visible in decision records.
|
|
- Tenant and platform policy packages are separated.
|
|
|
|
## Research Basis
|
|
|
|
Seeded by the policy decision point/enforcement point pattern, tenant
|
|
scoped authorization, API authorization, and CARING modeling notes.
|
|
|
|
## References
|
|
|
|
- NetKingdom platform identity/security architecture.
|
|
- Initial exploration: Authorization and access control.
|