feat(accounts): manage service accounts from account settings

[alukach]

Closes #547. Part of #491. Stacked on #566, now merged, so the diff is this branch alone: the feature commit, the immutable-subject commit, two review-fix commits, a redesign of the form and the list, a fix for writing trusts, owner-namespaced ids, and an account page that is where creating lands and where grants are edited, with the create form's product list, showing what it reaches and granting more from a new row.

What

The real version of the flow #495 mocked, built on the model (#563), the membership pages (#564) and account trusts (#566). Rebuilt on the trust model in one commit; what review changed follows as commits of its own.

Settings → Service Accounts appears for individuals and organizations alike, to whoever canManageAccount says manages the account. The list page loads each service account with its trusts, its grants and (from #570) its keys.

ServiceAccountForm — who it is (the name, and the id derived from it, shown as code with an Edit link the way the data-connection form shows its id), how software signs in (any number of GitHub workflows, each a card with the repository on its own row — owner/repo, or owner@id/repo@id for the immutable subjects GitHub mints for repositories created after July 2026 or opted in — then a Ref/Environment segmented control and its value, and the exact subject shown as you type), what it may reach (the products it reaches, each with Read / Read and write and a red X, and Grant a product, which adds a row with a dropdown of the owner's other products (each option the product's name over its owner/product path in small monospace), a Read / Read and write choice, and a green check that finalizes it, beside an X that cancels — the same ProductAccessList on the create form and the account's page; each title opens the product in a new tab, and the form holds its grants until it is submitted). The id is namespaced under the owner: {owner}--{id}, such as acme--nightly-sync, joined by the -- account-owned data connections already use. Two owners can each have a nightly-sync, a service account never takes a handle a person or organization might want (their ids cannot contain --), and no service-account id can equal an Ory identity id, which is a UUID. The form asks for the short id and shows the whole one; the action composes it. ServiceAccountSchema requires the composed form, and a membership's member id accepts it, which granting a namespaced service account a product needs. The general createAccount action no longer takes type=service: nothing posted it, and it created service accounts without the owner checks or the namespace. Submitting writes the account, its grants and its trusts, and redirects to the account's page, where each trusted workflow's example usage is a click away. Nothing has to run first, and the step carries nothing that expires.

ServiceAccountList — one row per account in the data connections' own ConnectionList/ConnectionRow: the name linking to the account's page, its id, a marker when it is disabled, and how many workflows it trusts and products it reaches.

ServiceAccountDetail, at /edit/account/{owner}/service-accounts/{id} — the account's page: the workflows it trusts as rows, each removed with a red X (captioned "Remove" on hover, labelled with the subject for screen readers), each with an Example usage link that opens the step the workflow adds in a modal, and the "Trust a GitHub workflow" dialog on the section header, which writes the trust and closes onto the new row; the products it reaches, each with Read / Read and write and a red X, and Grant a product, which adds a row with a dropdown of the owner's other products (each option the product's name over its owner/product path in small monospace), a Read / Read and write choice, and a green check that finalizes it, beside an X that cancels — the same ProductAccessList on the create form and the account's page, here saved as each is made (the check, a change of access, or an X), shown at once (useOptimistic) with the controls held while it saves; each title opens the product in a new tab so a viewer can check what it holds; and Disable and Delete set apart in a danger zone. The page resolves the account through managedServiceAccount and 404s unless it is under its own owner. The actions revalidate the list and the page. Delete confirms in an alert dialog whose submit runs the action (a plain button, not AlertDialog.Action, which would close the dialog before the action ran) and shows the action's message if it refuses; deleting removes the grants and the account with its trusts, then redirects to the list. The trust dialog's form lives inside Dialog.Content, so each open starts fresh. The page passes the data-proxy origin down for the example; without one, no example is offered.

The workflow snippet (src/lib/services/github-workflow.ts) is the aws-actions/configure-aws-credentials@v6 step pointed at the data proxy — sts-endpoint, audience = the proxy origin — naming the account in role-to-assume: arn:aws:iam::<service-account-id>:role/FullAccess, plus env pointing S3 clients at the proxy. From then on any S3 client in the job works, if the account trusts the workflow's subject. Depends on developmentseed/multistore#126: the action validates the credentials it exports with GetCallerIdentity, which the proxy answers once that lands.

AccountInfoHoverCard, the card an account name opens on hover anywhere in the app, marks a service account with the outlined "Service account" badge the picker and memberships table already use.

What this PR adds to the model: canManageServiceAccount(session, account, owner) — whoever manages the owner manages the service account, answered through canManageAccount on the fetched owner, so an admin is included, a disabled owner takes its service accounts out of reach with it (admins aside), and nothing that is not a service account qualifies; a disabled service account is still managed so it can be re-enabled or deleted. managedServiceAccount(session, id) in src/lib/accounts/service-accounts.ts is the one resolver the lifecycle actions (and, in #570, the key actions) go through: it loads the account and its owner and answers null for anything not managed. And AccountTrustsTable.create (schema-validated, conditional, AlreadyTrustedError) and delete, which were in #566 until review noted nothing there called them.

Server actions (src/lib/actions/service-accounts.ts): createServiceAccount, addGithubTrust, removeTrust, setServiceAccountDisabled, deleteServiceAccount, and for grants setProductAccess. Create loads the owner and requires an enabled individual or organization the caller manages — settled before any of its products are read, so the form can't be used to probe another account's catalogue — deduplicates the workflows and grants it was posted. The rest go through managedServiceAccount; setProductAccess also applies serviceAccountGrantProblem (read or write, the owner's products only), changes the grant the account already has rather than adding a second, touches only the account's own grants, and on none revokes by setting the membership Revoked, as a person's is. No action builds a workflow step: the page does, from the proxy origin. A disabled account takes no new trust, and a repeat is named for what it is. removeTrust deletes by the account's own key, so it can never touch another account's.

Stories

On this branch's deploy:

• ServiceAccountForm › Default — https://source-coop-ui-git-feat-service-account-management-radiantearth.vercel.app/?path=/story/features-service-accounts-serviceaccountform--default (submitting redirects in the app; Storybook cannot follow that, so the mocked action just resolves)
• ServiceAccountForm › NoProducts — https://source-coop-ui-git-feat-service-account-management-radiantearth.vercel.app/?path=/story/features-service-accounts-serviceaccountform--no-products
• ServiceAccountList › Default, Disabled, Empty — https://source-coop-ui-git-feat-service-account-management-radiantearth.vercel.app/?path=/story/features-service-accounts-serviceaccountlist--default
• AccountInfoHoverCard › ServiceAccount — https://source-coop-ui-git-feat-service-account-management-radiantearth.vercel.app/?path=/story/components-accounts-accountinfohovercard--service-account (hover the name)
• ProductAccessList › NothingGranted, SomeGranted, EverythingGranted, Saving, NoProducts — https://source-coop-ui-git-feat-service-account-management-radiantearth.vercel.app/?path=/story/features-service-accounts-productaccesslist--some-granted (controlled, so every control works, Grant a product included)
• ServiceAccountDetail › Default, Disabled, Empty — https://source-coop-ui-git-feat-service-account-management-radiantearth.vercel.app/?path=/story/features-service-accounts-serviceaccountdetail--default ("Example usage" opens the step in a modal; "Grant a product" adds the row to choose a product and its access; an access change shows while the mocked save runs, then springs back, since the mock saves nothing)
• WorkflowSnippet › Default, ImmutableSubject — https://source-coop-ui-git-feat-service-account-management-radiantearth.vercel.app/?path=/story/features-service-accounts-workflowsnippet--default
• GithubWorkflowFields › Empty, ImmutableRepositoryWithRemove — https://source-coop-ui-git-feat-service-account-management-radiantearth.vercel.app/?path=/story/features-service-accounts-githubworkflowfields--empty (controlled, so the stories hold the workflow in state and the fields can be typed into)

The form, the detail and the dialog use useActionState, so they are on the smoke test's cannot-render-under-jest list alongside the other action-state forms; WorkflowSnippet, GithubWorkflowFields and ProductAccessList render there. The stories and the Storybook mock build the step with githubWorkflowStep rather than carrying a copy of it.

Screenshots

The create form: the id derived from the name, one workflow card, and each product's access chosen in place:

The list, one row per account:

The id, derived from the name under the owner, and the same id opened for editing:

An account's page, where creating one lands. Each trusted workflow has Example usage; the products it reaches are listed with their access and an X, with Grant a product below:

After Grant a product: a row to choose the product and its access, finalized with the check:

A trust row, with the Remove caption showing on the X:

The grant row's dropdown, each product's name over its path:

The create form uses the same list and grant row, and holds its grants until it is submitted.

Example usage, opened from a workflow's row:

WorkflowSnippet on its own, with a subject in the immutable form pinned to an environment — the block scrolls sideways rather than wrapping the YAML:

GithubWorkflowFields as the create form stacks it, an immutable repository name pinned to an environment, with the Remove button:

A service account's hover card:

Testing

• npx jest — all suites pass, re-run after the redesign. service-accounts.test.ts: create writes the account, grants and trusts once each however many times a field was posted, and redirects to the account's page; refuses an unpinned workflow, a product the owner lacks and a bad role before writing; refuses a non-manager, a missing owner and a service-account owner, and reports a taken id on the short-id field; delete removes grants then the account and redirects to the list; a short id containing its own -- is refused; disable/enable; remove a trust by the account's key; trust one more workflow, refusing an unpinned subject, a repeat and a disabled account; every lifecycle action refuses what managedServiceAccount does not hand back. accounts/service-accounts.test.ts: the resolver hands back the account only when it is a service account whose owner is found and managed. github-workflow.test.ts: the step names the account and the proxy and carries nothing that expires.
• authz.test.ts: the manager rules — admin-over-organization refused, some other account offered as the owner refused, a disabled owner refused for its managers and allowed for an admin. account-trusts.test.ts: write keyed by account and identity, only once; AlreadyTrustedError; malformed rows refused before the table; delete by the same key.
• service-accounts.test.ts, setProductAccess: a product the account does not reach is granted as a member of the owner; one it reaches has its grant changed rather than a second added, and none revokes it (and is a no-op where there is no grant); a product the owner lacks, a role beyond read or write, and a non-manager are refused before any write; only the account's own grants are read.
• account-trusts.test.ts also asserts the create condition names identity by placeholder. Unit tests mock DynamoDB, so they could not catch the reserved word; it surfaced when a trust write failed on a deployment with "Attribute name is a reserved keyword; reserved keyword: identity".
• npm run type-check, next lint, npm run build-storybook — clean.

Docs and ADRs

data.source.coop: ADR-014 (source-cooperative/data.source.coop#232) describes this flow as amended with #566, and is amended again for the namespaced id (commit ae85ff72 on that PR), which replaces its "no reserved id namespace". docs.source.coop: the unattended-workflow guide (source-cooperative/docs.source.coop#34) will carry the workflow step this issues; it should read the way the AWS one does.

🤖 Generated with Claude Code

https://claude.ai/code/session_01REZWKgQy2PDETn6j9YpM4z

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
source-coop-ui	Ready	Preview	Sep 24, 2026 3:16pm UTC
source-cooperative	Ready	Preview	Sep 24, 2026 3:16pm UTC

[claude]

Claude finished @alukach's task in 2m 23s —— View job

---

Reviewing PR #567

• Gather context (PR description, diff, changed files)
• Review diff for correctness/security/best-practice issues
• Apply ponytail-review pass for over-engineering
• Check docs/ADR references in description
• Post final review

---

✅ No blocking issues — safe to merge.

Read through the full diff against origin/main: the actions in src/lib/actions/service-accounts.ts, the managedServiceAccount/canManageServiceAccount authorization funnel, the namespaced-id schema changes (SERVICE_ACCOUNT_ID_REGEX, serviceAccountId), the account-trusts table (including the reserved-word fix), the GitHub subject regex and workflow-snippet builder, and the UI components (ServiceAccountForm, ServiceAccountDetail, ProductAccessList, GithubWorkflowFields).

A few things I specifically checked and didn't find problems with:

• createServiceAccount (src/lib/actions/service-accounts.ts:65) settles the owner and canManageAccount before reading any of the owner's products, so it can't be used to probe another account's catalogue — matches the PR description.
• managedServiceAccount (src/lib/accounts/service-accounts.ts:44) is the single funnel every lifecycle action goes through, and correctly returns null for a missing account, a non-service account, or an owner that's gone/disabled (admins excepted, verified in authz.test.ts).
• removeTrust (src/lib/actions/service-accounts.ts:191) and deleteServiceAccount (:225) key strictly off the resolved account's own account_id, so neither can touch another account's rows; accountsTable.delete (pre-existing, unchanged here) transactionally removes the trusts alongside the account row.
• The {owner}--{id} namespacing is consistent end-to-end: ID_REGEX still rejects -- for person/org ids, SERVICE_ACCOUNT_ID_REGEX requires it, and ACCOUNT_ID_REGEX (used for Membership.account_id) accepts either form.
• GITHUB_ACTIONS_SUBJECT_REGEX correctly rejects a mixed mutable/immutable repository name (e.g. owner@123/repo, no id on the second half) since @ isn't in either alternative's mutable character class.
• setProductAccess (:257) revalidates role/ownership via serviceAccountGrantProblem before writing, and changes an existing grant in place rather than creating a duplicate membership.
• The general createAccount action (src/lib/actions/account.ts) no longer accepts type=service, closing the path that previously created service accounts without owner checks or namespacing.

Simplify (ponytail)

• src/lib/actions/service-accounts.ts:248 — managedFrom wraps managedServiceAccount(await getPageSession(), ...) and is called from exactly one place (setProductAccess). Inline it there; the indirection doesn't pay for itself at one call site.

Docs

The description names both docs this flow touches and either points at the amending PR or explains why it still holds: ADR-014 in data.source.coop (source-cooperative/data.source.coop#232) is called out as amended for the trust model and again for the namespaced id, and the docs.source.coop unattended-workflow guide (source-cooperative/docs.source.coop#34) is named as the doc that will carry this workflow step. Nothing in the diff looks like it moves a decision beyond what's already flagged there.

---

💰 Estimated review cost: $1.15 · 2m23s · 39 turns

[alukach]

Addressed. createServiceAccount now authorizes before any read on the owner the caller named, with a test asserting a non-manager triggers no product lookup. Also took both simplifications: GithubWorkflowFields (with githubSubject) is shared by the form and the dialog, and the idle states are defined once in @/types.

[alukach]

New commit: the subject pin accepts GitHub's immutable subject form (repo:owner@123456/repo@456789:…, per https://github.blog/changelog/2026-04-23-immutable-subject-claims-for-github-actions-oidc-tokens/) alongside the mutable one — both names carry ids or neither — and the form tells the user to name the repository the way its tokens do. Without this, no repository created after July 2026 could be trusted. Description updated.

[alukach]

Two review-fix commits, on top of the branch rather than amended into it, and #570 rebased onto them.

2ffba12 — settle a service account's owner before acting on it. Create loads the owner and requires an enabled individual or organization the caller manages, so an admin can no longer create one under a nonexistent, disabled or service account. canManageServiceAccount takes the fetched owner and answers through canManageAccount, so a disabled owner takes its service accounts out of reach (admins aside); managedServiceAccount in lib/accounts is the one resolver, and each action resolves the session once. Subjects and grant fields are deduplicated before anything is written, and a missing data-proxy endpoint fails the trust before it is written.

cfc05e3 — run the delete, restart the trust dialog, and give the parts their stories. The Delete submit was inside AlertDialog.Action, which closed the dialog before the action was dispatched, so it never ran; it is a plain submit now, and the dialog shows the action's message if it refuses. The trust dialog's form lives inside Dialog.Content, so reopening it offers a fresh form. WorkflowSnippet and GithubWorkflowFields have stories, and the stories and the mock build the step with githubWorkflowStep.

Description updated to match; stories and screenshots added.

[alukach]

New commit ba495d6 redesigns the form and the list, following the data-connection pages.

• The list is one row per account in the data connections' ConnectionRow: the name, the id, a marker when it is disabled, and how many workflows and products it has. Every control moves to the account's own page, /edit/account/{owner}/service-accounts/{id}, which renders the new ServiceAccountDetail: its trusts, its grants, and Disable and Delete in a danger zone. Delete redirects to the list.
• The form has one line of description per section. It shows the derived id as code with an Edit link, puts the repository on its own row with a Ref/Environment segmented control below it, and gives each product a None / Read / Read and write control in place of a checkbox that revealed a select.

Stories, screenshots and the description are updated. #570 is rebased, and its API-keys section now lives on the account's page.

[alukach]

New commits:

• 885bcf4 fixes writing a trust. DynamoDB reserves identity, and the create condition named the sort key bare, so every trust write failed with "Attribute name is a reserved keyword". It is named by placeholder now.
• d34fa69 namespaces a service account's id under its owner, {owner}--{id}, and links each product under "Can reach" to the product itself in a new tab. It also stops the general createAccount action from creating service accounts.
• 2c142cc fixes a trust's OpenAPI example id, and the latest commit sets the owner prefix flush against the editable id.

ADR-014 is amended to match on source-cooperative/data.source.coop#232. Description, stories and screenshots are updated.

[alukach]

New commit b1e11f1:

• Creating lands on the account's page. The post-create view, ServiceAccountCreated, is gone.
• Example usage per workflow. Each trusted workflow has an "Example usage" link that opens its step in a modal. The trust dialog closes onto the new row instead of showing the step.
• Grants edited in place. "Can reach" has a Read / Read and write control and Remove per product, and a form to grant another of the owner's products. It is backed by three new actions: grantProduct, setGrantRole and revokeGrant.

#570 is rebased, with its API keys section alongside. Description, stories and screenshots are updated.

[alukach]

New commit ce115aa makes the account's page use the create form's product list, ProductAccessList, in place of the product dropdown, role dropdown and Grant button. Every product the owner has gets None / Read / Read and write, saved as it is changed and shown at once. That also removes the "No products yet." that appeared when the owner had products but none were granted. One action, setProductAccess, replaces grantProduct, setGrantRole and revokeGrant. #570 is rebased; description, stories and screenshots are updated.

[alukach]

New commit: the account page's "Can reach" lists only the products the account reaches, each with Read / Read and write and a red X. Grant a product on the section header adds a row with a dropdown of the owner's other products; picking one grants it to read, saved at once. The create form keeps the full list. #570 is rebased; description, stories and screenshots are updated.

[alukach]

New commit b24adc7: granting a product now picks the product and its access (Read or Read and write) in one row, finalized with a Grant button, and it is the same component on the create form and the account's page. The form holds the grants until "Create service account"; the page saves each on Grant. #570 is rebased; description, stories and screenshots are updated.