Impersonation
- Seth Petry-Johnson
- Ali Neal
First introduced in 11.0.24, this feature aims to replace the legacy Impersonation feature which has been renamed “Log In As”.
Overview
The Impersonation feature supports the following use cases:
End user support, allowing a customer service representative to take some action on behalf of an end user that is having trouble.
Configuration testing, allowing an administrator to see what the site would look like for a specific type of user.
Training content creation, allowing a content author to capture screenshots under different scenarios.
The key part of the Impersonation feature is that actions taken while impersonating another user are recorded as being “performed by” the user that is actually logged in, not the account they are impersonating.
This is the primary difference relative to the legacy Impersonation feature, which did not properly capture the identity performing the action in the logs.
Feature overview
Enabling the feature toggle
As a beta feature, Impersonation can be enabled/disabled at the system level via the EnableImpersonation App Config setting.
This defaults to DISABLED.
Required permissions
In addition to the feature toggle being enabled, users must have the AdminArea.CanImpersonateUser permission.
Impersonating another user
When the feature is enabled, and you have the required permission, you will be able to impersonate a user via the quick actions menu on the Admin → Members page.
When you activate the Impersonation feature from the Admin area you will be taken to the impersonated user’s profile page. From there you can access their Learning Plans, modify their account, etc.
To end the impersonation session, click the “End Impersonation” button in the banner at the top of the page.
When you end the impersonation session you will be returned to the Admin → Members page.
Audit logs track the “logged in user” separately from the “active account”
When Impersonation is active, LearningBuilder keeps track of the “Logged In User” (person doing the impersonation) separately from the “Active Account” (person being impersonated).
This information is captured in various audit logs, such as the Workflow Log:
Limitations and business rules
Limitation | Reason |
|---|---|
Cannot impersonate a Sys Admin user | For security reasons, you cannot impersonate a user with the Sys Admin Role. |
Cannot impersonate a user with a greater privilege level than your own | For security reasons, you cannot impersonate a user with a greater privilege level than your own. |
Cannot access the Admin area while impersonating | Access to the Admin area is restricted until we can explore the security implications of allowing it. Configuration changes are not fully audit logged right now, so we want to restrict the potential for changes that are even harder to track back to the person making them. |
Cannot impersonate a user in an “Inactive” or “Pending Registration” status | The general purpose of the Impersonate feature is to “see what the other user would see”. A user account with an Inactive |