glm-5.1
5c820a41e9
Add 10 new tasks under tasks/architecture/ for Phase 0a (ADR writing): - 9 ADR tasks (026-034) with dependency-ordered structure - 1 review checkpoint task before Phase 0b spec writing ADR dependency graph (3 generations): Gen 1 (parallel): 026, 029, 030, 031, 032, 034 Gen 2 (depends on 029): 027, 028 Gen 3 (depends on 027+028): 033 Gen 4: review checkpoint Also mark all 34 prior implementation tasks as completed — they were finished but still showing as pending in the taskgraph.
2.6 KiB
2.6 KiB
id, name, status, depends_on, scope, risk, impact, level
| id | name | status | depends_on | scope | risk | impact | level | |
|---|---|---|---|---|---|---|---|---|
| architecture/adr-028-auth-irpc-service | Write ADR-028 — Auth as irpc service | pending |
|
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:
IdentityProvidertrait inalknet_core::auth— the contract that callers depend onConfigIdentityProvider— default impl, reads fromArcSwap<DynamicConfig>, no database neededAuthProtocolirpc service enum —VerifyPubkey,VerifyToken,ReloadKeys,CheckAccess— behindirpcfeature 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.mdexists- 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