Show deprovisioning event and date in the audit log - #635
Conversation
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? This change maps IdentityForgottenEvent to a new 'deprovisioned' audit log action and reorders AuditLogProjector::handle() so the deprovisioning entry is persisted before the identity's other audit log entries are anonymized; otherwise the newly created entry would be wiped immediately after. A projector test covers both the new entry and the existing anonymization behavior. Provide links to any relevant tickets, articles or other resources OpenConext/Stepup-RA#423
Why is this change needed? IdentityForgottenEvent was mapped to a new 'deprovisioned' audit log action and persisted, but AuditLogRepository::createSecondFactorSearchQuery() filters entries against an event allowlist that never included it, so the new entry was written but silently filtered out of the RA audit log page. Separately, the comment justifying the projector's insert-before-anonymise ordering had the mechanism backwards, and the projector test mocked findByIdentityId() to omit the just-inserted entry, so it couldn't have caught either issue. How does it address the issue? Adds IdentityForgottenEvent::class to the allowlist so the entry is actually returned to the RA UI. Corrects the ordering comment: inserting before anonymising means the new entry is included in the same anonymisation pass as the identity's other entries (its actor name gets wiped like everything else), not preserved as the old comment claimed. Updates the test to mock findByIdentityId() the way the real repository behaves (returning the freshly flushed entry alongside the pre-existing one), and asserts the new entry's actor name is anonymised too. Provide links to any relevant tickets, articles or other resources OpenConext/Stepup-RA#423
|
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
left a comment
johanib
left a comment
There was a problem hiding this comment.
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:
- Backfill is not idempotent — the
stepup:event:replayinstruction in the description will duplicate entries on a second run, or when run after new deprovisionings have already been projected live. - The chosen ordering intentionally erases the deprovisioning actor's name; worth confirming that is what the issue reporter wants.
IdentityRestoredEventhas no counterpart action, so the log can end on "deprovisioned" for an identity that is actually live again.
Details inline.
| // findByIdentityId() picks it up too, anonymising its actor name along with the | ||
| // identity's other entries. Anonymising first would query before this entry exists, | ||
| // leaving its actor name (typically the deprovisioning system/API actor) untouched. | ||
| $this->applyAuditableEvent($event, $domainMessage); |
There was a problem hiding this comment.
Backfilling via stepup:event:replay is not idempotent and will duplicate entries
applyAuditableEvent() assigns a fresh Uuid::uuid4() per invocation and there is no dedupe on (identityId, event, recordedOn). Unlike middleware:event:replay, the stepup:event:replay command recommended in the PR description does not wipe read tables, so every run adds another deprovisioned row for every past IdentityForgottenEvent. Running it twice, or running it after new deprovisionings have already been projected live, silently corrupts the audit log that RA(A)s are supposed to trust.
Suggested approach: either make the projector skip creating an entry when one already exists for this identity + event, or replace the free-form backfill instruction with a one-shot, guarded console command (or SQL migration) that inserts only missing rows. At minimum, document the "run exactly once, before the new code starts projecting live events" constraint prominently — a checklist item in a test plan is not enough for a production runbook.
| // Record the deprovisioning entry first so applyIdentityForgottenEvent's re-query of | ||
| // findByIdentityId() picks it up too, anonymising its actor name along with the | ||
| // identity's other entries. Anonymising first would query before this entry exists, | ||
| // leaving its actor name (typically the deprovisioning system/API actor) untouched. |
There was a problem hiding this comment.
The deliberate ordering erases who performed the deprovisioning
The comment is accurate about the mechanism, but the consequence deserves an explicit decision: for management-API deprovisionings the actor is a real SRAA, and folding the new entry into the same anonymisation pass replaces their name with CommonName::unknown(). The issue asked to show that and when an identity was deprovisioned, so this may well be fine — and it is consistent with how all other entries about a forgotten identity are treated — but the audit trail now cannot answer "who did this".
Suggested approach: if losing the actor is intended, say so in the comment ("actor name is intentionally anonymised, consistent with all other entries for a forgotten identity") instead of framing it purely as an ordering mechanic. If it is not intended, invert the order and exclude the new entry from the anonymisation pass.
| GssfPossessionProvenAndVerifiedEvent::class => 'possession_proven', | ||
| IdentityCreatedEvent::class => 'created', | ||
| IdentityEmailChangedEvent::class => 'email_changed', | ||
| IdentityForgottenEvent::class => 'deprovisioned', |
There was a problem hiding this comment.
IdentityRestoredEvent has no counterpart, so the log can end on "deprovisioned" for a live identity
Identity::restore() emits IdentityRestoredEvent, but it is absent from both $eventActionMap and AuditLogRepository::$secondFactorEvents. After this change an identity that was forgotten and later restored shows a terminal deprovisioned entry with nothing after it, which reads as "this account is gone" when it isn't. Pre-existing gap, but this change is what makes it visible.
Suggested approach: consider adding IdentityRestoredEvent::class => 'restored' to both maps in this PR (it needs an RA translation too, alongside the one already in OpenConext/Stepup-RA#531), or open a follow-up issue so it isn't lost.
|
Based on the title, I expected this to be easy 😅 One thing I don't understand yet: Why does middleware have a Lets discuss this PR before continuing. |
2 participants
Why is this change needed?
Prior to this change, deprovisioning an identity via the lifecycle API left no trace in the audit log.
AuditLogProjectorexplicitly skipped writing an entry forIdentityForgottenEvent, so RA(A)s had no way to see that, or when, an identity had been deprovisioned.How does it address the issue?
Maps
IdentityForgottenEventto a newdeprovisionedaudit log action, and reordersAuditLogProjector::handle()so the deprovisioning entry is persisted before the identity's other audit log entries are anonymized; otherwise the newly created entry would be wiped immediately after. A projector test covers both the new entry and the existing anonymization behavior.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
The issue asks for the audit log projection of already-deprovisioned identities to be updated too. This doesn't need new code: operators can backfill via the existing replay tooling once this is deployed:
Select
IdentityForgottenEventand theAuditLogProjectorwhen prompted. This re-dispatches all pastIdentityForgottenEvents through the projector, creating the missingdeprovisionedentries for already-deprovisioned identities.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— 4/4 passing./ci/qa/phpcs— cleanphpstan— no new errors (206 pre-existing errors, none touchingAuditLog*)stepup:event:replayin an environment with already-deprovisioned identities, confirmdeprovisionedentries appear with correct date/time