Synapse: Admin API to return an access token for any user of the server

Created on 18 Sep 2019  路  8Comments  路  Source: matrix-org/synapse

Description:

It would be useful for the server administrator to be able to grab an access token on behalf of any user of their server. As discussed with @ara4n it would be good to extend the 'whois' admin API to offer this functionality

This could be useful for admins of the server to perform actions on behalf of another user (e.g. a dedicated 'abuse' user or bots etc.) and could also be useful for (benign) account puppeting, e.g. provisioning of integrations etc.

admin-api feature

Most helpful comment

We may want to avoid creating a real device entirely, and just have a new access token that isn't related to a device. This has the advantage that it won't appear in your "Where you鈥檙e logged in" list, and won't cause any raised eyebrows from other users who see new unverified devices for the user.

All 8 comments

How should this play with devices, if an Admin "sudo's" into your account should it be a new device (which the user then should or should not be able to see in their devices list), should it just use a random device id?

Yeah, would definitely need to be a new device ID (in order to protect e2e messages, unless the user explicitly verified the device). Ideally we should show in some way that the device ID relates to an admin (in order to provide some visibility of activity to the user, and what the device relates to, otherwise I can see people being very scared and confused at random device IDs popping up). So, maybe a random device ID with a "system_admin_" prefix, or something?

Would probably make more sense to issue a new access token entirely to avoid situations where a user's set up is inadvertently modified by the puppeting actions.

To reiterate from the above conversation, it sounds like we want to:

  1. Allow an admin to create a new device + access token for a user.
  2. Give that new device a particular display name (or a prefix) which makes it obvious that it is an admin token.

We probably also need a way for the admin to delete the token once done with it. Maybe this can re-use the delete device API.

@rxl881 to be clear, this will result in a new entry in Element's "Where you鈥檙e logged in" list. Is that acceptable?

We probably also need a way for the admin to delete the token once done with it. Maybe this can re-use the delete device API.

could just call /logout?

We probably also need a way for the admin to delete the token once done with it. Maybe this can re-use the delete device API.

could just call /logout?

That would work too. I mostly wanted to mention it so that we remember to document what you should do afterward to remove the token.

We may want to avoid creating a real device entirely, and just have a new access token that isn't related to a device. This has the advantage that it won't appear in your "Where you鈥檙e logged in" list, and won't cause any raised eyebrows from other users who see new unverified devices for the user.

Was this page helpful?
0 / 5 - 0 ratings