alknet/tasks/architecture/adr-028-auth-irpc-service.md at bd38c94caec845e930d8bfa2cd9ecfb0f3ce1571

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.6 KiB

Raw Blame History

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

name

status

depends_on

scope

risk

impact

level

architecture/adr-028-auth-irpc-service

Write ADR-028 — Auth as irpc service

completed

architecture/adr-029-identity-core-type

narrow

medium

phase

implementation

Description

Write ADR-028 establishing that auth verification is provided via an irpc service protocol, with the IdentityProvider trait as the interface contract and ConfigIdentityProvider (ArcSwap-backed) as the default implementation.

This ADR defines the relationship between the trait-based path and the irpc path:

IdentityProvider trait in alknet_core::auth — the contract that callers depend on
ConfigIdentityProvider — default impl, reads from ArcSwap<DynamicConfig>, no database needed
AuthProtocol irpc service enum — VerifyPubkey, VerifyToken, ReloadKeys, CheckAccess — behind irpc feature flag
Future: StorageIdentityProvider (in alknet-storage) backed by SQLite — additive, not replacing the trait

The critical design point: callers go through IdentityProvider. The irpc service is one way to satisfy the trait. Feature-gating (irpc feature) means nodes that only do SSH tunneling don't need the service layer overhead. Both paths produce the same result — an Identity or rejection.

Acceptance Criteria

docs/architecture/decisions/028-auth-irpc-service.md exists
ADR follows established format
Context explains why a service layer is needed: for head nodes serving many users, in-memory key lookup doesn't scale; irpc provides async boundary for database-backed auth
Decision states: IdentityProvider trait is the contract; ConfigIdentityProvider is the default; AuthProtocol irpc service is behind feature flag; irpc path and trait path produce identical Identity results; StorageIdentityProvider in alknet-storage is a future additive impl
Shows AuthProtocol enum (VerifyPubkey, VerifyToken, ReloadKeys, CheckAccess) and AuthResult type
Consequences: minimal deployments use ArcSwap without irpc; production deployments wire SQLite-backed service; feature flag keeps core lean
References: research/services.md AuthProtocol, auth.md, research/configuration.md auth service approach, ADR-029

References

docs/research/services.md — AuthProtocol definition
docs/architecture/auth.md — IdentityProvider trait, Identity struct
docs/research/configuration.md — auth service approach
docs/research/integration-plan.md — ADR 028 entry, Phase 1.4

Notes

To be filled by implementation agent

Summary

To be filled on completion

2.6 KiB Raw Blame History