
Implementing Impersonation - duck
https://jamie.ideasasylum.com/2018/09/29/implementing-impersonation/
======
dtertman
> if possible, disable user notifications/emails when an account is being
> impersonated — or remind staff that impersonating a user will still generate
> emails, notifications, and dashboard events.

Never, ever disable notifications. Notifications are the only way the user has
to cross-check that the agent actually did the thing they were supposed to do,
and only that thing.

I worked for a large benefits outsourcing corporation. We had impersonation,
and we had a way for agents to cancel notification. A few agents realized they
could change a participant address, get a 401k loan, and then cancel the
notifications for those things. They used these combined capabilities to steal
from our participants.

~~~
martell
> Never, ever disable notifications. Notifications are the only way the user
> has to cross-check that the agent actually did the thing they were supposed
> to do, and only that thing.

Disagree here, when the user is not aware of the impersonation disabling
things like notifications and the ability of the admin to interact with
notifications is the correct thing to do so that the admin does not dismiss
other notification on behalf of the user or spam the user from activity the
user didn't do themselves. The user could think that their account has been
hijacked by an external actor which creates it's own set of trust problems for
the user with your product. (I would however, leave them enabled on a non
production environment; for testing purposes)

> I worked for a large benefits outsourcing corporation. We had impersonation,
> and we had a way for agents to cancel notification. A few agents realized
> they could change a participant address, get a 401k loan, and then cancel
> the notifications for those things. They used these combined capabilities to
> steal from our participants.

This sounds like a failure from the product and development team who designed
and implemented this system. If you are tracking the impersonation correctly
it should be easy to see internally that the user didn't change the address or
request a 401k loan themselves and a system should be in place to ensure that
such changes get flagged and reviewed.

Impersonation should generally only be used in 3 situations.

1\. With a user to reproduce a problem they are having. (In this case leaving
notifications enabled should be fine) Though you can use an external
integration like inspectlet to (and look at logs) replay user sessions.

2\. As read only impersonation to ensure the user world view is correct. (This
stops you from testing/navigating everything because some times you need to
POST or PUT to get to certain frontend pages or reproduce other user
behaviour) It is still very useful though in most cases.

3\. A write impersonation on a non production environment
(staging/devtest/locally). You can dump production data into one of those to
test deeper on the frontend.

In general, some kind of admin panel/support system should be used to do write
changes to a users account but lets say you need to do writes on production
with impersonations like your example above.

It is generally support staff that is using this feature to write on behalf of
the users (developers generally have access to way more and have all other
kinds of tools and knowledge at their disposal to manipulate user data)

I always wondered why support systems show staff members user details like the
last 4 digits of a SSN instead of hiding that information and having the
support member enter in the digits the user gives them to validate and unlock
more functionality like your situation above for the duration of the call.
This way the admins/support staff can not randomly decide to act on behalf of
users, they are also generally going to be on a recorded call so it is easy to
ascertain if the user actually needed the impersonation support. This means
that the review backlog from the flagged activities is minimal and easy for
another isolated team to go through/ heck you could even train some ai models
to do that part for you with some voice transcription.

~~~
dtertman
> when the user is not aware of the impersonation

I'm curious, so please don't assume ill intent. What's a valid use-case where
an event would be 1) done by an impersonator, 2) not driven by the person
being impersonated, and 3) produce a notification that should be squelched?

Your three use cases don't seem to lead me to those situations: In the first
one, you agree that notifications are OK. I agree with that.

In the second one, it's read-only, and so I wouldn't expect notifications to
be produced. If there are notifications about read-only aspects (your account
was accessed, e.g.), I suppose I'd be OK with them being suppressed, but I
think I'd still lean towards a custom notification (your account was accessed
by an administrator, e.g.).

In the third one, shouldn't you scrub your data while you dump it? Everywhere
I've ever worked that didn't scrub their data (i.e. set all of the email
addresses to nobody@testingmystuff.com) eventually regretted it.

------
n42
This is (one of) the big reason our team is moving over to Keycloak. It has
full support for token exchange/impersonation and has a full audit trail along
with it. You can get very granular about who can impersonate who.

------
sp332
Separating admins from users is generally a good idea, but it doesn't really
apply to the Facebook situation. They were trying to let users look at their
own profile from the perspective of another user. This is useful because if
you set a photo to be visible to "friends" and then you tag some people in the
photo, their friends can also see it. So instead of tracking down every person
you tagged and making sure, say, your mom isn't in every friend's friends
list, you can just view your profile as it appears to your mom and make sure
the photo isn't there.

------
J-Kuhn
Can confirm that impersonation will open a hole. Found my first security bug
10 years ago in moodle[1]. It allowed students to impersonate admins with came
with full access to the admin panel.

[1]:
[https://moodle.org/mod/forum/discuss.php?d=87972](https://moodle.org/mod/forum/discuss.php?d=87972)

------
fcolas
Nice read. And a related reading is "how we impersonate users" [1] by eager.io
(not related to them). I particularly like their sudo-button--smart

[1] [https://eager.io/blog/how-we-impersonate-
users/](https://eager.io/blog/how-we-impersonate-users/)

------
jimmcslim
Impersonation used to be built into the Auth0 dashboard, but they have since
removed it (or deprecated it for new accounts).

