Betreff: Allowing impersonation from permissions in AEM

[aem_noob]

Is it possible to assign permissions to custom group which can impersonate any user in AEM?

We can individually assign impersonator per user but is there a way to assign a group or user privilege to impersonate anyone?

We want to avoid giving this group/user administrator privilege/product profile.

With User Product profile, what permission will a user need or is admin access the only way?

[aanchal-sikka]

Who can impersonate?

• Only the users who have READ permissions in the /home/users path.

Who can add/configure impersonators?

• admin user
• A user can add impersonators to their account
• A user who is part of user-administrators group (this grants write access on target user)

The user-A would need to add user-B to the account of User-C as impersonator. Post this User-B would be able to impersonate as User-C.

User-A: Has write access to /home/users

User-B: Has read access to /home/users

[aem_noob]

Tried all the 3 things -

1. The user who will impersonate has /home/users jcr:all permission

2. User is added to admin group

3. User is part of user-admin group

Still the impersonation doesn't happen

org.apache.sling.auth.core.impl.SlingAuthenticator handleLoginFailure:
Unable to authenticate null: Impersonation not allowed.

[aanchal-sikka]

@aem_noob 

I guess previous post isn't clear. The user needs to be added as an impersonator. Who can add this user as an impersonator is also listed in previous reply.

The user would be able to impersonate, only after he is added as an impersonator.

So, if this user has write access on target user, then he first needs to add himself as an impersonator of target user, then he can impersonate.

[aem_noob]

So as more users keep on getting on-boarded the only way to be keep adding impersonator for each user to the special user?
Then we might have to look at creating a script/workflow to achieve this as suggested by @markus_bulla_adobe 

[aanchal-sikka]

@aem_noob 

That depends on how often do the users impersonate. If its a one off activity, they should be able to add themselves as impersonator and impersonate.

But, if its a frequent activity, then script would be needed as suggested by @markus_bulla_adobe 

[Sudheer_Sundalam]

Impersonating is done at per user account level. I don't think we can blanket add a user/group to impersonate any user.

[aem_noob]

@Sudheer_Sundalam- But admin is able to impersonate anyone so there should be a set of permissions that allow them to do that

[markus_bulla_adobe]

Any user can allow another user to impersonate him. This is not tied to special permissions. As mentioned in my initial response, the user will then be added to the list in the rep:impersonators property of the user node. The admin user is a very special case and has broad permissions in AEM that are specifically tied to this single user.

In short: Impersonation is not managed through permissions.

[markus_bulla_adobe]

Hi @aem_noob!

As @Sudheer_Sundalam has correctly stated, impersonation is handled on a per-user level and it is not possible to grant impersonation to groups. Impersonators are stored as "rep:impersonators" property (type: String[]) on the user node.

You did observer that the "admin" user is able to impersonate anyone. That is also correct. The "admin" user is a very special case in AEM as it has extensive permissions and many functionalities are specifically allowed for this one user. It is very different to any other, regular user in AEM.

That being said, you can certainly build an automation to add users as impersonators for other users.

In one of my customer projects we had the need to allow one specific "special" user as an impersonator for all existing users on the AEM instance. We handled this by observing the repository for newly created users and starting a custom workflow to add our "special"-user as an impersonator automatically.

This could also be extended to add all members of a certain group in an automated way but this might lead to loads of updates depending on the size of the group and the overall user base (basically A x B updates per change, where A is the number of members of the group and B is the overall number users on the instance). So I would not generally recommend going this route.

I'm also with you and would avoid to grant too many people admin permissions by assigning administrator privileges.

In general, the impersonation feature should be used with caution and I would not recommend to grant this privilege to too many users.

Would you mind sharing the underlying business use case? That would help to find a proper solution.

Hope that helps!

[aem_noob]

we have 15+ custom user groups with custom permissions defined in YAML.

The users (power users/admin) want to impersonate everyone in the system. We had previously suggested to pick one user from each group and adding the impersonator manually to basically see what each group is able to see and access in AEM.

But the user is keen to impersonate everyone to fill in for any person from any team/group who might not be available for work. The client has workflows which involves multiple groups and sometimes the workflows are targeted towards specific users.

[markus_bulla_adobe · Accepted solution]

Hi @aem_noob!

The impersonation feature should be used sparsely and is not recommended for day-to-day business tasks like the ones you are mentioning. It seems that you are trying to solve a sub-optimal business process with a technical workaround. I highly recommend to reconsider the solution approach.

Using the impersonation feature undermines proper auditing of user actions which results in more complexity for certain kinds of issue analysis on the long run. Acting impersonated as another user will obscure who actually did what.

With regards to your use cases:

• "see what each group is able to see and access in AEM"
  Proper quality assurance of permissions is important and logging in as a member of a certain group is the best way to handle this. I would recommend to create actual test users for every business role in the project that is assigned with the according group membership(s). E. g. to verify permissions of the "Content authors EMEA" group, I would create a test user "test-content-authors-emea" and assign the relevant group(s). The super user can then login to this account and verify the permission setup.
• "fill in for any person from any team/group who might not be available for work. The client has workflows which involves multiple groups and sometimes the workflows are targeted towards specific users"
  Your business workflows should be designed in a way to allow for delegation if a single user is unavailable. Unavailability of users is a regular event (e. g. due to vacations, sick leave or changing roles) so your business workflows should reflect this.
  Therefore assigning workflows to specific users rather than a group is a discouraged practice. Using impersonation to work on a task that has been assigned to someone else will obscure the change logs.
  There are two things that I would recommend:
  
  • Ensure that workflows are always assigned on a group level to avoid "stale" or "stuck" workflows that are assigned to a single person who might be unavailable. This way, there is always someone to step in and work on the task.
  • If you are unable to implement workflow assignments on group level for some reason, an admin user can still step in and re-assign a workflow to another user. He should do this with his own (admin) user to make the process transparent and auditable. Using impersonation as a tool for for delegation does clearly sound like a misuse of the feature.

Hope this helps!