1

With asp.net Membership I've been using Christ Akkermans' Forms Authentication User Impersonation to permit an administrative user to login as any other client. This is critical for the Support role. Can anyone suggest how to do this with Identity 2.0? Even a general idea would be helpful to get me started; so far it's a bit bewildering.

EDIT Thanks for the thoughts on security and auditing the actions of the Support users.

Any thoughts on how to actually do the impersonation?

Without some form of impersonation, every action has to accommodate the User doing something on her own and a Support person (or the User's parent) doing it on behalf of the that User. That's a headache of repeated tortuous logic in the code and a lot of conditional text in every page (e.g. "My" and "Your" become "@(User.FirstName)'s" and "his" or "her".)

Improve this question
2
  • 1
    It's a very insecure design to allow users who aren't the users to impersonate others. That doesn't mean you can't allow support people to act on their behalf, and see what they would see.. But there are so many legal and ethical ramifications that most people just don't consider (and lets face it, how many programmers are willing to tell their bosses that doing this would be legally questionable in many situations?) You have to be able to correctly tell the difference between a real user and a support user acting on the users behalf (and the user should be able to as well). Commented May 3, 2014 at 3:04
  • @ErikFunkenbusch Thanks, it does seem reasonable to keep track of whether an action was done by the user, or a support person acting on behalf of the user. Commented May 5, 2014 at 13:46

1 Answer 1

Reset to default
2

We carried a tenant in the claims collection.

When a regular user logged they already had tenant assigned, but when a support person logged in they had to also choose the tenant. This let us audit what a support does as well as the let the support user "act" like a regular user in the system.

** EDIT **

I know this comment doesn't apply to every type of system but I would suggest you train support to "lead the user/business to the water" not try to "drink the water for them". Let support see everything they need to see, able to change things they absolutely have too, but only in regards to setting the user/business up to finish the process they are trying to do. They own it, not support. This doesn't have to be hard-coded, it can easily be a training issue. If support really are performing business functions then I would consider them a class of user and you'll have to build that complex functionality throughout the application.

Improve this answer
Sign up to request clarification or add additional context in comments.

1 Comment

I think you're telling me to be sure to audit what the support people do. Actually, we will be logging what everybody does, but I take your point (and @Erik's) point above to make it explicit which actions were done by a support person on behalf of the user.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.