GitHub user aicam created a discussion: Privacy considerations for the admin
"log in as user" (impersonation) feature
## 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.
GitHub link: https://github.com/apache/texera/discussions/6071
----
This is an automatically sent email for [email protected].
To unsubscribe, please send an email to: [email protected]
