Implementing impersonation in an ASP.NET Core Web application

I am working at a proof-of-concept for porting an ASP.NET MVC application to an ASP.NET Core API + Angular SPA. One of the features of the existing application is the ability of an admin (typically tech support) to impersonate any other user.

This is done through ASP.NET impersonation, but one side effect is that all actions/audit data generated by the impersonator is linked to the impersonated user which is NOT OK in my opinion (from an audit point of view, actions should be linked to the actual person performing them).

Until ASP.NET 5, ASP.NET Core does not support impersonation directly, but there seems to be a way to code it.

I am wondering about an alternative approach that would be easier to understand and also make it work for the legacy project + new one (migration can be done over a long period).

Instead of acting as another user entirely, I implement impersonation by:

• pushing current user rights into some backup tables
• I transfer the impersonated user rights to the impersonator

This leads to the same effect, but with a framework-agnostic approach. Auditable actions are correctly generated and the legacy application can read the impersonation state from the database (instead of trying to set up some kind of session transfer between the two applications).

Since I could not find any article related to such an implementation, I am wondering what are the downsides of such an approach.

posted about 4 years ago

CC BY-SA 4.0

Alexei‭

5003 reputation 112 101 690 488