[Wish] Impersonating Other User

[Wish] Impersonating Other User

  
Hi,

I'd like for you to consider implementing some kind of mechanism in the platform to allow us to quickly be able to impersonate one user, after logging in with another.

As the platform is now, permission areas on pages are hardcoded to the UserId that logged in and therefor cannot be used when I want to impersonate another user, maintaining my current user logged in.

Perhaps some kind of platform built-in function that would allow us, in an action, to redirect the permission areas control to other user.

What do you think?
Hi Gonçalo,

Thanks a lot for your feedback. Your idea will be taken into account by our product management team.

Regarding that same subject, you can see the forum topic "HelpDesking", in which exactly the same need is discussed.

In short, the problem of impersonating has two different perspectives:
  • Data Access Permissions - tipically, imposed by database queries that only retrieve the data that the logged in user can in fact see - for example, seeing only MESSAGES sent to you. The UserId filter comes from the Login_GetUserMasterId() function in Enterprise Manager;
  • Permission Areas - You can only access the functionalities you have permission to. These restrictions built-in the OutSystems Agile Platform.
One idea would be to create an "Impersonate" functionality in Enterprise Manager - the simplest solution would be to have a "Impersonate Login" screen that has no need for a password and is only accessible to administrators, nevertheless this obviously has security and data problems - for example, if you perfom any actions, they will be logged as being done by the impersonated user. To have a full solution we would have to have a cue telling us that the logged in user is being impersonated by some other user.

Again, thanks a lor for your feedback!

Best Regards,
Daniel Lourenço
Hi Gonçalo

I know that we discussed this on the phone today, but seeing this topic in this forum I would like to leave my personal opinion on this.

From my understanding, in all computer systems, impersonating a user is basically "entering a state in which you are someone else, even though you initially authenticated as yourself". That means that your whole context changes - you are now userX instead of Gonçalo. This is how it is done with linux (su), windows (with kerberos and authentication delegation).

So an "impersonation" feature is essentially a synonym of "sub-login in as being a separate user". In OutSystems, that would mean calling an action that logs you in using a different credential, possibly keeping your initial identity stored somewhere. That can easily be done when thinking of the baseline login (there are several Login actions, and you don't need to know the password) and probably (I am not sure) you even have primitives in Enterprise Manager to login without a password.

Sure thing, Enterprise Manager is not prepared by default with this - it has no standard mechanism to make that operation, and also does not have a mechanism of defining who can impersonate who, and I believe that it is what Daniel will forward to OutSystems R&D. And it sure will imply a change in the Style Guide and some built-in primitives. I can sure think of some ideas:

- There should be "impersonate" and "revert_to_original" public actions in EM;
- The original user would have to be stored somewhere (site property)
- There should be an indication that a user is impersonating (probably in the header) BUT all actions would be made by the impersonated user and not the original;
- No trace of the action having been done by the original user would exist - for all purposes, it was an impersonation.

Can you think of something that could be useful here?

Cheers,

APN
Hi Acácio,

I agree with much of what you wrote.
A few notes:

- Yes, there is a difference with this impersonating request and the "su" command, for example, since we usually need some kind of reference of who was impersonating who, for security and auditing reasons.
- "The original user would have to be stored somewhere (site property)." - I would prefer to store it in a session variable not in a Site Property, since an impersonation is done for a specific session. This session variable would be shared by enterprise manager to all eSpaces for them to use, through a function like the ones that exist now.

Executing a sub-login seems the best idea and the one that would involve less change in the Platform itself.

Hi Gonçalo:

I didn't mean (it makes no sense) to use a site property, but instead a session variable. I thought of the latter, but wrote the former. But essentially we agree on this - and would involve zero change to the Agile Platform, it can be done entirely in Enteprise Manager / Style Guide.

Cheers,