fix(authz): emit authorization events before role and tag writes - #1934

Follow-up to #1924, which fixed the ordering for the OpenFGA assignment endpoints. The role and tag management endpoints had the same inversion.

Problem

In role.rs and tag.rs the authorize_* helpers ran the authorization check and the write (begin_write → catalog write → commit), and the handler called emit_authz only on the result. So:

• the write committed before the authorization event was dispatched, and
• a post-authz write failure (DB error, unique conflict) came back as an AuthZError and was logged as an AuthorizationFailedEvent — even though authorization had succeeded.

Denials were always audited correctly (the check runs first); this is about the success / write-failure path and the ordering.

Fix

Each helper is split at its first side effect. The pure require_*_action check feeds emit_authz; the write runs after and its failures are mapped with authz_to_error_no_audit, so nothing is logged a second time under the wrong label.

All 19 handlers from the issue:

• role.rs: create_role, delete_role, update_role, update_role_source_system — new apply_* helpers, plus check_role_action shared by the three that resolve a role first.
• tag.rs: create/update/delete_tag_definition — new apply_* helpers, plus check_tag_definition_action.
• tag.rs: the 12 set_*_tag / delete_*_tag handlers — the shared flows become check_set_tag_on_target / check_delete_tag_from_target, producing an AuthorizedTagChange that apply_tag_to_target / remove_tag_from_target consume after the emit.

Two behavioural notes:

• The immutability guards (SystemRoleImmutable, ManagedRoleImmutable, reserved tag definitions) and the tag scope/value validations move to the write side. They are request rejections, not authorization denials, so they now follow an AuthorizationSucceeded event instead of being reported as an authorization failure. This matches remove_role_member in role_membership.rs, which already ran reject_managed_role after the emit. The HTTP status and error type for those rejections are unchanged.
• check_tag_definition_action also replaces two verbatim copies of the same resolve-and-authorize block in the tag read paths (get_tag_definition, list_tag_attachments).

No API, schema or config change.

Tests

Five new regression tests in role_ops.rs / tag_ops.rs drive the real handlers and assert on the dispatched authorization events via a new CapturingAuthzListener helper. Each triggers a write that can only fail after authorization succeeded:

Each asserts the attempt is audited exactly once as a success and that no AuthorizationFailedEvent is emitted. All five fail against the unfixed code (verified by reverting role.rs + tag.rs and re-running): the create cases see 1 success event instead of 2, the update/delete cases see a failure event instead of a success.

They do not discriminate delete_role, update_role_source_system or the 12 set/delete tag handlers — those have no deterministic post-authz write failure to trigger. Those paths are covered by the existing role_ops.rs / tag_ops.rs behaviour tests, which still pass (27 + 39).

Locally: cargo clippy clean on the default, --no-default-features and test-utils feature sets, cargo +nightly fmt --check clean. The --all-features clippy legs need libclang/cmake and were not run locally — CI covers them.

Release notes

Role and tag management endpoints now dispatch the authorization audit event before applying the write, so a crash between the two can no longer apply a change that was never audited. A write that fails after a successful authorization check (for example a duplicate name) is no longer reported in the audit log as an authorization failure.

Summary by CodeRabbit

• Bug Fixes
  • Authorization audit events are now recorded in the correct order for role and tag operations.
  • Authorized requests that later fail during persistence no longer produce duplicate or misleading authorization failure events.
  • Improved consistency across role management and tag operations, including create, update, delete, apply, and remove actions.
  • Existing protections for system roles, managed providers, and transactional changes remain enforced.