I would like my Apex code to know the difference between me being actually logged in as a particular Salesforce user, versus being logged in as an administrator and impersonating the user (because I clicked on his name and selected "Login").

I cannot find a documented way to do this, and knowing that this is the nature of impersonation, don't necessarily expect to find a documented API call that tells me this. But Salesforce definitely knows the difference, at least in the UI, and Logout while you're impersonating just stops the impersonation but leaves you logged in as the administrator again.

So, is there a way for Apex code to tell that it is actually an administrator impersonating a user?

  • Why do you want to do this? – ReidCarlberg Dec 20 '13 at 14:23
  • I'm going to guess maybe you want to find out if an end user is actually performing certain actions or changes, vs. an admin logged in as them? If not, I agree with @ReidCarlberg, why do you want to do this? – Chris Duncombe Dec 20 '13 at 14:28
  • This is a good question: Salesforce-UI clearly can distinguish between the two cases, but I'm not sure if it's accessible via SFDC. I suggest trying some test cases: create/edit records while logged in as another user, and see who the resulting Record Owners are, who the Last Modified By are, etc. Do all the forensics you normally would do. – Scott Pelak Dec 20 '13 at 16:00
  • I would only want to know so I can log that the request was from impersonation. I have a logging object where I record some permanent logging information. – dwright01 Dec 21 '13 at 0:14

No. As far as the code is concerned, the effective user is the user performing the action. Any records created by an administrator logged in as a user will have their createdby and lastmodifiedby audit fields set to that user, and userinfo.getuserid() will return the user being logged in as. This is the same behavior as System.runAs() in test methods, with the exception that code can detect if it is being run in a test method. There's nothing you can do, such as examining the session ID, etc, that would give you any clue at all, unless you know how to decrypt the session ID (hypothetically; presumably this is how the UI knows).

| improve this answer | |

Adding on to Daniel's post, there is a different class called SessionManagement that will return some, if not all of the AuthSession attributes for the current session. This way, you can determine the type of session for the current session.

Map<String,String> currentSessionAttributes = Auth.SessionManagement.getCurrentSession();
String sessionType = currentSessionAttributes.get('SessionType');
//If sessionType == 'SubstituteUser', act on logged-in-as user.

Details on the SessionManagement class can be found here.

| improve this answer | |

It's not foolproof, but querying the AuthSession looks promising.

Unfortunately, there doesn't appear to be an easy way to find the AuthSession records that correspond to the current SessionID - How can I find the AuthSession that corresponds with the current Session Id?

However, an impersonator will get AuthSession SessionType of SubstituteUser.

A session created when one user logs in via another user. For example, if an administrator logs in as another user, a SubstituteUser session is created. Source

They will also lack LoginHistoryId, LoginType, LogoutUrl, and LoginGeoId field values. The former is particularly interesting, as it shows they never really "logged in".

As a very rudimentary check from Apex:

List<AuthSession> authSession = [Select Id from AuthSession where UsersId = :UserInfo.getUserId() and SessionType = 'SubstituteUser'];
Boolean hasLoggedInUser = !authSession.isEmpty();

Of course, this won't handle cases where the actual user is also logged in at the same time. You could do some additional checks to see if there are other active sessions for the same UsersId.

Alternatively, on the client side you could check for the presence of a RSID cookie. If this exists then the current session is using the login as functionality.

Unfortunately you can't directly check for the presence of this cookie in Apex as it doesn't have the apex_ prefix. Maybe write a new Apex accessible cookie client side if RSID is detected.

| improve this answer | |
  • This is an interesting theory. I think I'll try it out. – sfdcfox Apr 26 '17 at 2:57
  • how could we check impersonation in lightning component because document .cookie not access in component? – Anurag Bhardwaj Nov 15 '17 at 17:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.