Decide the RBAC model: token-claim roles vs stored per-publisher roles, and admin bootstrap #27

New issue

Closed

opened 2026-09-19 19:58:49 +00:00 by toasterson · 1 comment

toasterson commented

2026-09-19 19:58:49 +00:00

Owner

Part of #24

Maintainer decisions — 2026-09-22

Deferred beyond v1 by the maintainer: local ingestion suffices, and CI will deliver a completed multi-package .p5p and notify an import script (#38). Authenticated REST publishing, its OIDC/RBAC decisions and provider provisioning are not v1 release gates. Preserve this ticket and its research/dependencies for later work; no later milestone was selected. Do not provision credentials or an identity provider as part of v1.

These decisions supersede conflicting earlier scope below. This update records maintainer decisions, not implementation or test completion.

Earlier brief and context

Question

Who may publish to which publisher, and where is that decided? The plan proposes admin / publisher / reader roles stored in {repo}/publisher/{name}/rbac.db and granted via /admin/rbac/* endpoints; the existing middleware already parses a roles claim from the JWT.

Grill on:

Source of truth: roles stored in the repository (plan), roles asserted by the IdP in token claims (e.g. ips_publishers, Forgejo/Keycloak groups), a static mapping in pkg6depotd.kdl, or a hybrid (claims for identity, stored grants for authorization).
Bootstrap: how the first admin is created (config file, CLI on the server host over the admin unix socket, first-token-wins?).
Granularity: per publisher only, or also per package stem / per operation (publish, delete, manage roles)?
Global admin scope for operators vs per-publisher admins.
Auditability: is a grant/revoke log required for v1?
Interaction with unauthenticated read access (the depot stays anonymous-readable for pkg(1)).

Blocked by the release scope (does v1 need RBAC at all?) and by the IdP decision (which claims exist). Record as an ADR; the resolution should let /to-tickets slice #19.

Links

Informs #19

Part of #24 ## Maintainer decisions — 2026-09-22 Deferred beyond v1 by the maintainer: local ingestion suffices, and CI will deliver a completed multi-package .p5p and notify an import script (#38). Authenticated REST publishing, its OIDC/RBAC decisions and provider provisioning are not v1 release gates. Preserve this ticket and its research/dependencies for later work; no later milestone was selected. Do not provision credentials or an identity provider as part of v1. These decisions supersede conflicting earlier scope below. This update records maintainer decisions, not implementation or test completion. <details> <summary>Earlier brief and context</summary> ## Question Who may publish to which publisher, and where is that decided? The plan proposes `admin` / `publisher` / `reader` roles stored in `{repo}/publisher/{name}/rbac.db` and granted via `/admin/rbac/*` endpoints; the existing middleware already parses a `roles` claim from the JWT. Grill on: - Source of truth: roles stored in the repository (plan), roles asserted by the IdP in token claims (e.g. `ips_publishers`, Forgejo/Keycloak groups), a static mapping in `pkg6depotd.kdl`, or a hybrid (claims for identity, stored grants for authorization). - Bootstrap: how the first admin is created (config file, CLI on the server host over the admin unix socket, first-token-wins?). - Granularity: per publisher only, or also per package stem / per operation (publish, delete, manage roles)? - Global admin scope for operators vs per-publisher admins. - Auditability: is a grant/revoke log required for v1? - Interaction with unauthenticated read access (the depot stays anonymous-readable for `pkg(1)`). Blocked by the release scope (does v1 need RBAC at all?) and by the IdP decision (which claims exist). Record as an ADR; the resolution should let `/to-tickets` slice #19. ## Links - Informs #19 </details>

toasterson added this to the Release 1 (server only) milestone

2026-09-19 19:58:49 +00:00

toasterson added the

wayfinder:grilling

label

2026-09-19 19:58:49 +00:00

toasterson added a new dependency

2026-09-19 19:59:13 +00:00

#25 Define what 'v1.0 server release' must include and its acceptance criteria

toasterson added a new dependency

2026-09-19 19:59:25 +00:00

#28 Choose the OIDC provider and token flows for CI publishers and humans

toasterson added a new dependency

2026-09-19 19:59:32 +00:00

#19 RBAC Model to authorize people to admin endpojnts

toasterson referenced this issue

2026-09-19 19:59:46 +00:00

Wayfinder map: Release 1 (server only) #24

forge removed this from the Release 1 (server only) milestone

2026-09-22 12:12:48 +00:00

toasterson commented

2026-09-27 13:13:45 +00:00

Author

Owner

Closed as out of scope for Release 1 (wayfinder): remote publication, OIDC and RBAC are deferred with no target release (maintainer, 2026-09-22; ADR-004, ADR-015). Deciding the RBAC model has nothing to unblock until then. The research in #33 and the design in docs/ai/plans/2026-04-09-publish-api-oidc.md remain the starting point when this is re-charted.

Closed as **out of scope for Release 1** (wayfinder): remote publication, OIDC and RBAC are deferred with no target release (maintainer, 2026-09-22; ADR-004, ADR-015). Deciding the RBAC model has nothing to unblock until then. The research in #33 and the design in `docs/ai/plans/2026-04-09-publish-api-oidc.md` remain the starting point when this is re-charted.

toasterson referenced this issue

2026-09-27 13:14:15 +00:00

Wayfinder map: Release 1 (server only) #24

toasterson closed this issue

2026-09-27 13:14:43 +00:00