Skip to content

This is an internal working record, not an everyday instruction. It was written while the system was being rebuilt, for whoever maintains it. If you are here to do today's work, use the everyday documents instead: Procedures · Processes · Runbooks · The working day, step by step

Platform Identity / Session / Impersonation — Current Source Addendum

  • Status: CURRENT-SOURCE ADMIN/SUPPORT RUNBOOK ADDENDUM / EVIDENCE REQUIRED
  • Current source refresh: PLATFORM_IDENTITY_CURRENT_CONSUMER_REFRESH_2026-08-09.md
  • Consumer matrix: PLATFORM_IDENTITY_CURRENT_CONSUMER_MATRIX_2026-08-09.md
  • Read-only preflight: RBR-IDENTITY-001-READONLY-CURRENT-SURFACE-PREFLIGHT.md
  • Parent Runbook: PLATFORM_IDENTITY_IMPERSONATION_ADMIN_SUPPORT_RUNBOOK.md
  • Phase implementation: USER HOLD

1. Use This Addendum When

Use this document for current incidents or questions involving:

  • unexpected login or redirect;
  • session expiry or logout;
  • actor/subject confusion during impersonation;
  • Admin Console tenant selection;
  • password change/reset behavior;
  • Provider Credential Show/Save identity;
  • a provider or business action executed under an unexpected user/tenant;
  • incomplete actor/subject/request evidence.

Do not begin by changing roles, sessions, passwords or provider settings.

2. First Response

Record before any action:

environment and source SHA
time/timezone
physical person operating the browser
logged-in original username
effective displayed username
target tenant
whether impersonation banner is present
page/API/action
request ID if available
expected result
actual result

Then stop replay of any high-impact action.

credential Show/Save
password change/reset
provider send/sync/create
record mutation
impersonation start/end

3. Determine Current Identity Mode

Classify exactly one current mode.

Direct user

Actor = logged-in user
Subject = same user
Tenant = session tenant

User impersonation

Actor = original Super Admin
Subject = target user
Tenant = target tenant

Tenant-only impersonation

Actor = original Super Admin
Subject = none
Tenant = selected tenant

Admin tenant override

Actor = original Super Admin
Subject = none
Tenant = explicit route target
Mode = route-specific API override

System/integration

Actor = job/provider/system identity
Subject = none unless explicitly mapped
Tenant = explicit binding

If mode is unclear, do not perform a consequential action.

4. Current Source Facts

login regenerates session ID
impersonation start/end does not visibly regenerate session ID
session TTL is 20 hours
own-password change uses effective scalar user/tenant
password update does not visibly revoke other sessions
physical Super Admin status remains based on original session
strict typed principal is route opt-in

These are source facts, not accepted future policy.

5. Login Diagnosis

Symptoms

  • valid credentials rejected;
  • wrong tenant/user loaded after login;
  • duplicate username suspicion;
  • legacy password rehash failure;
  • unexpected default-page redirect.

Safe sequence

  1. confirm exact submitted username without recording password;
  2. inspect active username count across approved tenants using read-only evidence;
  3. classify password hash type without returning the hash;
  4. inspect role/default-page metadata;
  5. inspect request/error evidence;
  6. only after authorization, perform one controlled login scenario.

Stop conditions

  • more than one active user shares the username and no accepted realm policy exists;
  • a login scenario would use a real user account without consent;
  • evidence requires password/hash export;
  • current deployment/source identity is unknown.

Important

A login run changes session state and LAST_LOGIN; it is not part of a purely read-only review.

6. Unexpected Logout Or Session Expiry

Read:

source/config identity
PHP session configuration
session storage class and health metadata
cookie attributes without value
proxy/TLS path
request/error logs
browser time/timezone

Do not:

  • read raw session payloads;
  • copy cookies into tickets/chat;
  • extend session TTL globally during diagnosis;
  • disable Secure/HttpOnly/SameSite;
  • create a second independent session mechanism as a workaround.

Classify:

SESSION_EXPIRED_EXPECTED
SESSION_STORAGE_LOST
COOKIE_NOT_SENT
PROXY_TLS_MISMATCH
APPLICATION_LOGOUT
UNKNOWN

7. Impersonation Diagnosis

Before start/end

Confirm:

physical Super Admin
exact target tenant
exact target user or tenant-only mode
reason/authorization record if required by current operation
sensitive actions planned during the session

Current warning

tenant-only impersonation
!= target user role acceptance

Sensitive actions during impersonation

Treat the following as separate policy questions:

  • Provider Credential reveal/replacement;
  • own-password change;
  • password reset;
  • role/menu/module/config changes;
  • provider calls;
  • irreversible business commands.

Current source success does not prove accepted policy.

Response-loss recovery

Impersonation state lives in the current PHP session. After an unknown response:

  1. inspect the banner and current effective tenant/user;
  2. inspect request evidence;
  3. do not repeat start/end blindly;
  4. do not proceed with another sensitive action until mode is certain.

8. Provider Credential Show / Save Identity Procedure

This section supplements the provider Runbook. It owns only identity/session questions.

Before Show

Confirm:

current mode: direct / user impersonation / tenant-only
physical actor
effective subject
target tenant
Admin Console role
exact allowlisted credential key
business reason

Do not capture the credential value in evidence.

Current source behavior

Super Admin or role 1 Admin Console session
+ selected tenant check for non-Super Admin
+ allowlisted secret
-> one plaintext reveal response

After Show

  • inspect only as long as required;
  • use Hide or leave the page;
  • do not paste into chat, tickets, logs or screenshots;
  • verify no network/log capture contains the value;
  • record only actor, tenant, key, request ID, time and result class.

Before Save

Confirm:

  • intended tenant and provider;
  • expected current revision;
  • rollback owner/value source;
  • provider verification is a separate step;
  • removal is not implemented as empty Save.

Unknown result

If Save response is missing:

  1. do not submit again;
  2. reread safe configured/revision metadata;
  3. classify committed/not committed/unknown;
  4. only repeat after absence is proven;
  5. verify provider connectivity separately.

Non-implications

Credential updated
!= Provider authenticated
!= Provider reachable
!= Provider action authorized
!= old sessions revoked

9. Own-Password Change

Current helper uses effective scalar user and tenant. Before a password change:

  1. confirm direct versus impersonated mode;
  2. confirm whose password the page/API resolves;
  3. stop if the physical actor and effective subject differ and policy is not explicit;
  4. confirm session-revocation expectation;
  5. prepare user notification and recovery if required.

After an authorized change, verify separately:

password row changed
current session behavior
other controlled session behavior
impersonation state
user notification

Do not assume the latter four from the password-row update.

10. Super Admin Password Reset

Before reset:

physical Super Admin identity
explicit target tenant/user
approved reset reason
new credential delivery owner
active-session policy
impersonation policy

After reset:

  • verify the exact target row only;
  • do not test by exposing the password;
  • confirm whether existing sessions remain active;
  • confirm whether the user was notified;
  • record request/correlation evidence without credential content.

11. Logout Versus Reset

Reset
= clears selected UI/menu/browser state
!= logout

Logout
= destroys current PHP session
!= all-session revocation

Current logout and impersonation-end actions are GET actions. Do not use links or embedded content to trigger them during evidence collection.

12. Actor / Subject / Request Evidence

For a sensitive event, a complete evidence row should be able to answer:

who physically acted?
which user was represented?
which tenant was targeted?
which mode was active?
which request performed it?
which result was observed?

Current diagnostic and request contexts may store those facts in different places. If only actor or only subject is available, classify evidence as PARTIAL; do not fill the missing identity by inference.

13. Common Problems

Page shows wrong tenant after Admin Console navigation

  • inspect direct versus impersonated mode;
  • inspect selected tenant and effective getClientId();
  • inspect Admin header target;
  • do not change tenant data to match the page.

Credential Show available unexpectedly

  • record physical actor, subject, tenant and role;
  • inspect route/handler access without clicking Show again;
  • compare direct and impersonated modes;
  • do not remove the role or feature globally during diagnosis.

Password changed but old device still works

  • current source does not establish other-session revocation;
  • inventory session storage and controlled sessions;
  • treat revocation as a separate policy/command gap.

Logs show Admin but business result belongs to target user

  • original diagnostic actor and effective subject may be stored separately;
  • join by request/correlation evidence;
  • do not rewrite logs or business rows.

Tenant-only impersonation passes but field role fails

  • tenant-only mode is not field-role evidence;
  • repeat only with an approved target-user session in a separate authorized run.

14. Escalation Packet

Collect:

source/deployed SHA
environment/config reference
physical actor
effective subject
target tenant
identity mode
controlled account/role IDs
page/API/action
request/correlation IDs
safe session/cookie configuration metadata
safe result/error
before/after identity mode
current Wiki guidance
recovery attempted

Exclude:

password/password hash
session ID/cookie
credential/plaintext/ciphertext
authorization header
provider token
raw session payload
broad user data

15. Current State

core source:
CURRENT

consumer refresh:
COMPLETE

read-only evidence package:
DEFINED

current environment/session evidence:
NOT RUN

privileged action evidence:
NOT RUN

policy acceptance:
OPEN / PARTIAL

M3 / M4:
NO

---

Source: docs/runbooks/PLATFORM_IDENTITY_CURRENT_SOURCE_ADDENDUM.md — ctc repository · This page is an English translation of the source document. Identifiers, file paths and code symbols are unchanged.