Show deprovisioning event and date in the audit log

[kayjoosten]

Why is this change needed?

Prior to this change, deprovisioning an identity via the lifecycle API left no trace in the audit log. AuditLogProjector explicitly skipped writing an entry for IdentityForgottenEvent, so RA(A)s had no way to see that, or when, an identity had been deprovisioned.

How does it address the issue?

Maps IdentityForgottenEvent to a new deprovisioned audit log action, and records that entry before the identity's audit trail is anonymized. The actor name is still intentionally anonymized, consistent with every other audit-log entry for a forgotten identity.

Every audit log entry's id is now derived deterministically from its source event's stream id and playhead (AuditLogEntry::idFor()), rather than a random uuid4. AuditLogProjector::applyAuditableEvent() skips creating an entry when one with that id already exists, so projecting or replaying the same event twice is a no-op for every event type, not only IdentityForgottenEvent. The backfill command below uses the same id scheme, so it is idempotent with the live projector.

IdentityForgottenEvent was also restored to AuditLogRepository::$secondFactorEvents, so these new deprovisioned entries are actually returned by the RA audit-log API and not silently filtered out.

The RA-side rendering of this new action (translation for "Deprovisioned") is in OpenConext/Stepup-RA#531 — the audit log template there already renders any action generically, so no other RA change was needed.

Retroactive backfill

This PR ships a dedicated one-shot backfill command for historical IdentityForgottenEvents:

bin/console stepup:audit-log:backfill-deprovisioned

Rollout/runbook notes:

• only the lifecycle (deprovisioning) API needs to be disabled while it runs; the rest of the application can stay up
• the command and the live projector are not atomic with each other: if an identity is deprovisioned live while the backfill is processing that same identity's historical entry, both can race to insert the same deterministic id. The database's primary-key constraint rejects the second insert, which rolls back that transaction and exits the command non-zero. Nothing is left half-applied, so simply re-running the command picks up whatever is still missing.
• rerunning the command is always safe: it inserts only missing deprovisioned rows
• do not use stepup:event:replay for this backfill

Follow-up

IdentityRestoredEvent audit-log handling stays out of scope for this PR and is tracked separately in #637.

Provide links to any relevant tickets, articles or other resources
Closes OpenConext/Stepup-RA#423

Test plan

• php vendor/bin/phpunit -c ci/qa/phpunit.xml --filter AuditLogProjectorTest
• php vendor/bin/phpunit -c ci/qa/phpunit.xml --filter AuditLogRepositoryTest
• php vendor/bin/phpunit -c ci/qa/phpunit.xml src/Surfnet/StepupMiddleware/MiddlewareBundle/Tests/Console/Command/BackfillDeprovisionedAuditLogEntriesCommandTest.php
• php vendor/bin/phpunit --configuration=ci/qa/phpunit.xml (full unit + integration suite)
• php vendor/bin/phpunit --configuration=ci/qa/phpunit.xml --testsuite=database
• ./ci/qa/phpcs
• php vendor/bin/phpstan analyse --memory-limit=-1 --no-ansi -c ./ci/qa/phpstan.neon
• After deploy: run bin/console stepup:audit-log:backfill-deprovisioned in an environment with already-deprovisioned identities and confirm deprovisioned entries appear with correct date/time

[kayjoosten]

Update after code review: the initial version wrote the `deprovisioned` entry but `AuditLogRepository::createSecondFactorSearchQuery()` filters against an event allowlist that didn't include `IdentityForgottenEvent`, so it was silently dropped from the RA audit log query — the feature was a no-op. Fixed in the latest commit, along with a corrected (previously backwards) code comment and a test that now mocks `findByIdentityId()` the way the real repository behaves (returning the freshly flushed entry, not omitting it).

Also worth calling out explicitly: `stepup:event:replay` is not idempotent (new UUID per replayed entry), so the retroactive backfill described above should only be run once per environment.

[johanib]

Nice, focused change — the ordering rationale holds up: AuditLogRepository::save() flushes, so the re-query in applyIdentityForgottenEvent() genuinely picks up the new entry. Ran AuditLogProjectorTest in an isolated worktree, 4/4 green.

One blocker before this can go out, plus two points worth a decision:

1. Backfill is not idempotent — the stepup:event:replay instruction in the description will duplicate entries on a second run, or when run after new deprovisionings have already been projected live.
2. The chosen ordering intentionally erases the deprovisioning actor's name; worth confirming that is what the issue reporter wants.
3. IdentityRestoredEvent has no counterpart action, so the log can end on "deprovisioned" for an identity that is actually live again.

Details inline.

[johanib]

Based on the title, I expected this to be easy 😅
The findings above seems genuine on first read.

One thing I don't understand yet: Why does middleware have a stepup:event:replay AND a middleware:event:replay.

Lets discuss this PR before continuing.

[kayjoosten]

Take a good look at why there are 2 types of replay. Also we need to take a look at how this will work with mega big data. As far as we know atm the replay is not doable in production.

possible thoughts.

• how can we split the replay
• Do we need to do the whole replay
• how do the replays work now
• are they idempotent

[kayjoosten]

Why a new command instead of the existing replay commands:

• middleware:event:replay wipes and rebuilds all read models from the full event store, too broad and risky just to backfill one gap.
• stepup:event:replay replays through the live AuditLogProjector, which would re-run its anonymization logic against identities that were later restored (corrupting current audit data), and it doesn't check for existing entries, so reruns would duplicate them.

stepup:audit-log:backfill-deprovisioned avoids both: it only reads IdentityForgottenEvent rows, writes directly (skipping the projector), checks for existing entries first (idempotent), and batches writes so it scales fine.

[johanib]

Update release notes + @johanib does final check

[johanib]

Went through it again. The approach is solid 🥇
Still some comments to clarify and cleanup. Then it should be ready to merge.

The collision scenario is covered nicely with the reverting transaction.

[johanib]

I was wondering why this was suddenly no longer the case. Turns out, in the 2015, the deprovision deleted everything. Then, in 2022, that was replaced by anonymisation.

[johanib]

🎊