Skip to content

Allow instance admins to impersonate users #5068

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
gtsiolis opened this issue Aug 5, 2021 · 3 comments
Open

Allow instance admins to impersonate users #5068

gtsiolis opened this issue Aug 5, 2021 · 3 comments
Labels
component: dashboard feature: admin dashboard meta: never-stale This issue can never become stale needs visual design team: webapp Issue belongs to the WebApp team type: feature request New feature or request

Comments

@gtsiolis
Copy link
Contributor

gtsiolis commented Aug 5, 2021

Problem to solve

For instance admins, it could be useful to impersonate users so that they can see what a user sees. This can be helpful for debugging issues or helping out users by taking actions on behalf of the user.

See also relevant discussion (internal). Cc @svenefftinge @geropl @jankeromnes

User Flow

  1. An instance admin could go into /admin, search for a user, open their profile, and click an Impersonate action button.
  2. It should be clear on the user interface when you are impersonating a user.
  3. During impersonation it should be clear how to stop impersonating a user.
@securitymirco
Copy link
Contributor

A few thoughts on my end

  • we should consider to log who has been impersonated by whom and when as well as what they did/access
    • we might want to make certain logging available to the users / clients as well so they can see when we used that action
  • we should consider gathering consent, some web applications adopted that already (e.g. a checkbox with "allow Gitpod Support Staff to access my account" which remains active for a couple of hours of something (ideally just the time we usually need to go in and check what we have to)
  • we really need to make sure there are no logical flaws here (e.g. by directly accessing related links), if some unauthorised user can trigger this action we have real problem

@securitymirco
Copy link
Contributor

securitymirco commented Feb 1, 2022

I would also like to add the following - let's carefully evaluate the business value of this feature request against the potential attack surface we create with that as well as the potential results (information disclosure, reputation damage etc.).

If ever exploited this would have severe consequences and at the same time there is always an uncertainty on introducing possible bugs/vulnerabilities that remain undiscovered (to us).

@stale
Copy link

stale bot commented Jun 12, 2022

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the meta: stale This issue/PR is stale and will be closed soon label Jun 12, 2022
@gtsiolis gtsiolis added meta: never-stale This issue can never become stale and removed meta: stale This issue/PR is stale and will be closed soon labels Jun 12, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
component: dashboard feature: admin dashboard meta: never-stale This issue can never become stale needs visual design team: webapp Issue belongs to the WebApp team type: feature request New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants