Draft: fix(authz): query the organization ancestor in resolveTuples

Bojan Marjanovicrequested to merge
bmarjanovic/449-authz-organization-ancestor into main

Summary

resolveTuples (internal/authz/middleware.go) only queried the repository and namespace as relationship ancestors, so the ADR-021 Organization Administrator bootstrap tuple -- an organization-level owner relationship, bound to the organization itself rather than to any namespace or repository -- was never fetched. An Organization Administrator with no separate, explicit namespace- or repository-level role assignment was therefore denied, not granted the implicit bootstrap access ADR-021 guarantees.

The issue's suggested fix direction assumed this needed a namespace data-model change first, since namespaces.entity_id is deliberately opaque and non-UUID (ADR-007/ADR-022). That turned out not to apply here: Subject.OriginID already carries the organization's UUIDv7 whenever Origin == OriginOrganization (relationships.proto's ORIGIN_ORGANIZATION: "origin_id is the organisation UUID"), so no migration is needed -- the fix adds it as a third ancestor object only in that case.

Test plan

  • TestResolveTuples_OrganizationScopedIdentityAddsOrganizationAncestor (new): organization-scoped identity with a real OriginID adds the organization ancestor; an empty OriginID adds none; a OriginGitLabFederated identity's OriginID (the GitLab instance UID, not an organization) is never added.
  • Full internal/authz/... suite passes, including the existing TestAssembly_EveryActionReachesGLAZ object-list assertion (unaffected, since its fixture identity carries an empty OriginID).
  • golangci-lint run ./internal/authz/... clean.
  • No e2e scenario catalog update: this is an internal authz-middleware correctness fix, not a new user-facing format scenario.

Related to #449 (closed)

Merge request reports