User offboarding does not revoke Artifact Registry role assignments in IAM

Problem

AR role assignments exist only as tuples in the IAM relationships store, with no Rails record. Nothing in any Rails offboarding flow deletes them, and AR's authorization never rechecks Rails state, so the tuples are the only thing that severs AR access once a user is gone.

Verified current behavior

  1. User deletion. Users::DestroyService destroys every Member row, but never touches IAM. The user's relationships tuples, identities row, and principals row all persist. The lookup query joins identities to translate the principal back to a user id, so artifactRegistryRoleAssignments returns these orphaned assignments with a null assignee, ghost rows in member lists, forever.
  2. Blocking/banning/deletion and access. Access dies at token issuance, a blocked or deleted user cannot mint the short-lived AR token. Residual access is bounded by the token lifetime (5 minute default, 12 hour maximum, tokens cannot be revoked before expiry per ADR-020). So for these flows the orphaned rows are a hygiene and correctness problem, not a live access hole.
  3. Organization member removal. This is the dangerous case. Org member removal does not exist in Rails yet, but when the Organizations GA work builds it, deleting the organization_users row will not change the user's home organization_id (the sharding key). AR never calls back to Rails during request processing and validates tokens locally (ADR-020 architectural constraint), so a removed home-org member would still authenticate, still mint AR tokens carrying the org claim, and their tuples would still grant access through GLAZ, renewable indefinitely. Tuple revocation must be part of the org removal design or the removal does not remove AR access at all. (Caveat: if the GA design makes home-org membership irremovable and offboarding means deactivation or banning, this collapses into case 2.)

Proposal

This is in scope for the interim closed beta.

  • IAM already has the primitive: DeleteRelationshipsByFilter deletes every tuple for a set of subjects in one call. Vendor the RPC and call it from the user deletion flow (an event-store subscriber on the deletion path, following the Members::DestroyedEvent pattern).
  • The cleanup spans three IAM tables. The filter delete covers relationships only, the identities and principals rows for a deleted user also persist and should be swept, otherwise garbage accumulates invisibly.
  • Ensure the future org member removal design includes AR tuple revocation, and revisit the grant-side membership check (same_organization? compares home orgs today, it should become an organization_users lookup once multi-org membership is real).

Open questions

  • Ownership: Rails calling the filter delete, or IAM consuming a user deletion event?

Related: ADR-020 (authentication flow, no-callbacks constraint, token irrevocability), ADR-021 (authorization), #602144 (closed) (grant wrapper), #605677 (closed) (revoke wrapper), #601665 (closed) (owner role assignments sync).

Edited by 🤖 GitLab Bot 🤖