User Journey: Rescue access

"I want to get my colleague back into the system, or shut the account down." The administrator sets a new password for one colleague, then locks or unlocks the account. The journey is done when the colleague can sign in again, or when the account is shut and the administrator has said why.

The tenant administrator: an account inside the tenant that holds iam::accounts:reset_password, iam::accounts:lock and iam::accounts:unlock. The trigger is a support call, because a colleague is locked out, or because a compromise is suspected. It starts when the administrator opens Rescue access for one account, and ends when the account is usable or shut.

This is the administrative half of the credentials topic. The member's own half is Protect my account, and the record of what happened is Audit sign-ins.

1. Find the colleague. The administrator opens the screen from the account list and reads the account: username, full name, type and email. The system resolves the account and shows its security state beside it.
2. Read the security state. The administrator reads whether the account is locked, the failed attempt count, the last sign-in and whether a password change is required. A run of failed attempts tells the administrator which story this is.
3. Set a new password. The administrator types a new password twice and resets it. The system checks the password against the policy, and stores the new hash. The member can sign in with it at once.
4. Force a change on the next sign-in. The administrator asks the member to choose their own password at the next sign-in. No operation carries this over NATS, so the screen cannot offer it.
5. Lock or unlock. The administrator locks an account that must be shut, or unlocks one that was locked by failed attempts. The system writes the lock flag on the login record, and clears the failed attempt count on unlock.
6. Leave. The administrator goes back. The account list shows the new state.

One screen. The account being rescued, its security state, the password form and the actions are panels of that screen, because the administrator thinks of them as one decision.

The screen writes a password hash and never reads one back, so password_hash, password_salt and totp_secret stay off it.

All three write subjects are declared in ores.iam.account_messages. iam.v1.accounts.reset-password needs iam::accounts:reset_password, iam.v1.accounts.lock needs iam::accounts:lock, and iam.v1.accounts.unlock needs iam::accounts:unlock. A tenant administrator who holds the role has all three, so each is exists.

1. No forgot-password or self-service recovery. Nothing lets a member who cannot sign in start recovery. The only password subjects are iam.v1.accounts.change-password (signed in, own account) and iam.v1.accounts.reset-password (administrator only). There is no request subject, no recovery token and no message path. The candidates are iam.v1.accounts.request-password-reset and iam.v1.accounts.complete-password-reset.
2. No activate or deactivate. An account has no active flag. The only state an administrator can change is login_info.locked. A lock can be lifted, but an account cannot be retired and later restored.
3. The reset flag cannot be set over NATS. password_reset_required exists on login_info, account_operations_service::set_password_reset_required implements it, and the HTTP route uses it. No NATS subject calls it, and iam.v1.accounts.reset-password writes a new password directly. The two surfaces disagree: over HTTP the member must choose a password at the next sign-in, over NATS the administrator has already chosen it.
4. Locking does not end sessions. iam.v1.accounts.lock writes the login record only. A session that is already signed in stays open until it expires. The candidate is the same session-end operation that Audit sign-ins needs.

• Protect my account — the member's own password change, when they can still sign in
• Audit sign-ins — the failed attempts and sessions that explain why this account is locked
• Bring someone in — create the account when the colleague in the support call has none
• Sign in — where the password you set is first used, and where the forced change happens

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

• User Journeys