User Journey: Audit sign-ins

"I want to see who is signed in, what they are doing, and who is failing to get in." The administrator reviews the active sessions, the session activity and the failed attempts for the tenant. The journey is done when the administrator can account for every open session, or has raised the ones that cannot be explained.

The tenant administrator: an account inside the tenant that may read sessions and login records. The trigger is a routine review, an incident, or a support call. It starts when the administrator opens Audit: sign-ins, and ends when they leave it.

This is the record of what actually happened. The member's own half is Protect my account, and the repair is Rescue access.

1. Open Audit. The administrator opens Audit: sign-ins. The screen is an event log, not a versioned entity, so it carries no versions, no diff and no revert. Its only action is Refresh.
2. Filter. The administrator narrows the view by account, period and event.
3. Review the active sessions. The administrator reads one row for each session with no end time: account, client, address, country and start time.
4. Read the session activity. The administrator reads the duration and the byte counters for a session, as a time series of samples.
5. Review the failed attempts. The administrator reads the failed attempt count, the last attempt address and the lock state for each account. A locked account explains a support call; a burst of failures explains an incident.
6. Refresh. The screen re-reads the same subjects. There is nothing to edit here, and no history to browse.
7. Leave. The administrator goes back, and raises the sessions that cannot be explained.

One screen. The filters, the active sessions, the session activity and the failed attempts are panels of that screen rather than separate screens, because the administrator reads them together.

session_samples is a message shape, not an entity: no table backs it, and the samples are declared in the operation model. The session row holds the running byte totals; the samples hold how those totals moved.

The only action on the screen is Refresh, and it re-reads the subjects in the table above. There is no write step, so the screen carries no versions, no diff and no revert.

iam.v1.sessions.list is partial: it pages every session with offset, limit and order, and takes no account filter, so the screen cannot ask for one account's sessions. It is declared by ores.iam.session.

iam.v1.sessions.active and iam.v1.sessions.samples are partial for a stronger reason. Both subjects exist in ores.iam.session_messages and ores.iam.session_samples_messages, and both handlers reply with success and no rows. The BFF answers the active sessions from the session repository, so that panel works in the browser today while the NATS path does not. Nothing serves the samples, over either transport.

iam.v1.sessions.delete is partial: it removes the audit row, it is keyed by the composite storage key, and it needs iam::sessions:delete, which is not a permission of its own. Only a holder of the iam::* wildcard can call it, so it is not the administrator action this screen needs.

1. No subject for the auth events. ores_iam_auth_events_tbl holds one row per login, failure, logout and token refresh, with hourly and daily continuous aggregates over the same table. No subject reads it. The candidate is iam.v1.auth_events.list.
2. No subject for the session statistics. ores_iam_session_stats_daily_vw, ores_iam_session_stats_hourly_vw and ores_iam_session_stats_aggregate_daily_vw exist as TimescaleDB continuous aggregates with no subject. The candidate is iam.v1.sessions.statistics.
3. No operation to end another account's session. The repository method session_repository::end_session writes the end time, but only the logout path calls it for the caller's own session. The candidate is iam.v1.sessions.end, scoped to the tenant. A lock does not help, because iam.v1.accounts.lock leaves open sessions open.
4. The activity and the audit data have no read path in the browser. The session samples have neither a working subject nor a BFF route. The auth events and the statistics are reachable only by SQL. Until the subjects exist, the session-activity panel must state that the data is not available.

• Rescue access — lock or reset the account whose attempts you are reading
• See who has access — the roster view of the same accounts and their sign-in state
• Protect my account — the member's own view of the sessions and failed attempts shown here
• Change someone's access — strip the roles from an account whose sessions you cannot explain

• Identity and Access Management
• How do I add a PlantUML diagram?
• Credentials journeys

• User Journeys