Privacy considerations for the admin "log in as user" (impersonation) feature

[aicam]

Context

We're adding an admin-only "log in as user" (impersonation) feature: issue #6060, PR #6061. It lets an admin log in as a specific user directly from the admin dashboard (/dashboard/admin/user).

Why we built it: Texera uses Google OAuth for login, so admins can't sign in with a user's credentials. Today, when a user reports a problem (a broken workflow, a dataset or computing-unit issue), we have to ask them to share their datasets, computing units, and workflows just to reproduce it. Impersonation lets an admin reproduce and debug user-specific issues directly.

How it works today (the "simple" version):

• Backend: an admin-only endpoint POST /admin/user/impersonate/{uid} mints a JWT for the target user via the same code path as a normal login.
• The admin's own token is stashed client-side, and a "Stop impersonating" menu item restores the admin session.
• Guards: an admin cannot impersonate a non-existent user (404), an INACTIVE user (400), or another admin (403).

The privacy concern

The minted token is indistinguishable from a real login for that user. While impersonating, an admin can see and act on everything the user can: private workflows, datasets, computing units, and so on. As implemented today there is:

• No consent from the user being impersonated.
• No audit trail — no impersonatedBy marker on the session and no server-side log of who impersonated whom and when.
• No scoping — impersonation grants full read/write access, not read-only.

A faculty member raised the concern that this is a meaningful privacy surface: an admin can access a user's private data without the user's knowledge or consent. We'd like to get the community's input before this becomes established behavior.

What we'd like input on

1. Audit trail — should every impersonation be logged server-side (admin id, target id, timestamp, duration), and/or carry an impersonatedBy claim in the JWT so downstream actions stay attributable to the real admin?
2. Consent / notification — should the impersonated user be notified (e.g. email) or have to opt in beforehand?
3. Scope — should impersonation be read-only by default, with writes disabled or separately gated?
4. Visibility — should there be a persistent banner while impersonating, and should impersonated actions be flagged in activity logs?
5. Governance — should the whole feature sit behind an install-level config flag (off by default) so deployments can opt out entirely?

The current PR (#6061) implements the simple version; we're happy to layer any of the above on top, before or after merge, based on what the community thinks is the right bar here.

Thoughts very welcome, especially from anyone who has built support-login / impersonation features and dealt with their privacy and compliance implications.

[chenlica]

This feature is related to what system admins can do with each user's resources, including workflows, datasets, CUs, etc. It needs to be discussed carefully as it is related to privacy. As it has a low priority, I suggest we don't spend effort on this feature for now.