alknet/tasks/architecture/adr-031-forwarding-policy.md at 19b3d3a078afbc1cee842f3e195b9ea09fcbdf94

Files

glm-5.1 19b3d3a078 docs: write Phase 0 architecture foundation — ADRs 026-034, spec docs, and task updates

Phase 0a — ADRs (9 new):
- ADR-026: Transport/interface separation (three-layer model)
- ADR-027: Crate decomposition (core, secret, storage, flowgraph, napi, CLI)
- ADR-028: Auth as irpc service (AuthProtocol behind feature flag)
- ADR-029: Identity as core type (Identity + IdentityProvider in alknet-core)
- ADR-030: Static/dynamic config split (ArcSwap, ConfigReloadHandle)
- ADR-031: Forwarding policy (rule-based allow/deny, TransportKind-aware)
- ADR-032: Event boundary discipline (domain, irpc, call protocol boundaries)
- ADR-033: OperationEnv universal composition (three dispatch paths)
- ADR-034: Head/worker terminology (replace hub/spoke)

Phase 0b — New spec documents (7):
- identity.md, services.md, interface.md, configuration.md,
  storage.md, flowgraph.md, secret-service.md

Updated existing docs:
- auth.md: reference identity.md for canonical definitions, add AuthProtocol
- open-questions.md: resolve OQ-12, OQ-16, OQ-18, OQ-22, OQ-23-25
- README.md: add all new docs, ADRs 026-034

Marked 19 architecture tasks as completed.

2026-06-07 09:32:58 +00:00

2.3 KiB

Raw Blame History

id, name, status, depends_on, scope, risk, impact, level

name

status

depends_on

scope

risk

impact

level

architecture/adr-031-forwarding-policy

Write ADR-031 — Forwarding policy

completed

narrow

low

phase

implementation

Description

Write ADR-031 establishing the forwarding policy model for channel_open_direct_tcpip access control.

Currently any authenticated client can open a channel to any destination. This ADR defines ForwardingPolicy, ForwardingRule, and TargetPattern as part of DynamicConfig (reloadable without restart).

Key design decisions from the research:

Default-allow for migration compatibility (preserves current behavior)
Default-deny is recommended for production
Rules are evaluated per-channel-open, matched against the authenticated Identity from IdentityProvider
TransportKind match in rules enables transport-specific restrictions (e.g., WebTransport clients restricted to alknet-* channels)
OQ-12 resolved: start with global rules + principal matching from Identity.scopes; per-user scope from peer_credentials.metadata.scopes via IdentityProvider
OQ-16 resolved: add TransportKind match in ForwardingRule; WebTransport clients can be scoped
OQ-18 resolved: IdentityProvider owns scopes, ForwardingPolicy consumes them

Acceptance Criteria

docs/architecture/decisions/031-forwarding-policy.md exists
ADR follows established format
Context explains the security gap: any authenticated client gets unrestricted access
Decision states: ForwardingPolicy with allow/deny rules, TargetPattern matching, default-allow for migration, TransportKind-aware rules, ForwardingPolicy is part of DynamicConfig (reloadable), Identity.scopes consumed by policy
Includes ForwardingRule and TargetPattern type signatures
Consequences: operators can restrict access per identity, per destination, per transport; default-allow preserves backward compatibility
Resolves OQ-12, OQ-16, OQ-18 (reference in ADR)
References: research/configuration.md, auth.md, open-questions.md

References

docs/research/configuration.md — ForwardingPolicy section
docs/architecture/auth.md — Identity.scopes and IdentityProvider
docs/architecture/open-questions.md — OQ-12, OQ-16, OQ-18
docs/research/integration-plan.md — ADR 031 entry, Phase 1.3

Notes

To be filled by implementation agent

Summary

To be filled on completion

2.3 KiB Raw Blame History