Plugin Impersonation

The plugin registration tool of MS Customer Engagement already have an option to define the calling user for any plugin step:

Then why we need user impersonation explicitly in plugin code?

• Because the run in user’s context property of a step makes the whole plugin code of that step run on this user’s context.What if we just want to impersonate a user to access some record which isn’t otherwise accessible to the calling user? Yes, in that case, we need explicit user impersonation in the plugin code.
• Impersonation gives the Customer Engagement developer more flexibility to target a particular action in a plugin they would like to run with elevation permissions.  The rest of the plugin actions can be run as

There are 2 pre-requisites of user Impersonation:

• The user (impersonator) must have the ActOnBehalfOf privilege or be a member of the PrivUserGroup group in Active Directory.
• Setting the CallerId property of the organization Web service proxy.

User impersonation is very useful if you want to be able to do the following:

• Test the correct implementation of security roles.
• Check which records can be seen by which users if sharing is being used.
• Search for charts or views belonging to different users.

ex 1:  Let’s say you have a complex scenario where you shared a record using automatic sharing in your code to certain users. Not to test whether these users can access the record properly is a time-consuming task. But using user impersonation in.Net code you can write a test suite where you can test the access to this record for a set of a user to whom you shared.

So you see how easy it is to do something using user impersonation whereas it would have taken time to do the same thing from the front end.

To impersonate a user, we have to set the CallerId property on an instance of OrganizationServiceProxy before calling the service’s Web methods.

ex 2: You have to give an on-demand custom workflow to users where the custom workflow is doing tasks which is out of the privilege of the user executing the workflow.

The problem is whenever we run the workflow on-demand, we get the UserId and IntiatingUserId as follows:

• UserId: User running on-demand workflow
• InitiatingUserId: User running on-demand workflow

And whenever any workflow get trigger automatically

• UserId: workflow owned
• InitiatingUserId: Triggering user

So in this scenario, out of the box, we can never get the user having sufficient permission as context user for workflow. So to overcome the problem, we can pass the user-id of some admin(the user having sufficient permission) in code as shown below:

Function to get user-id by full name

public Guid getUserId(IOrganizationService service, string userName)
 {
  Guid systemUserId = Guid.Empty;
   try
   {
    QueryByAttribute queryByAttribute = new QueryByAttribute("systemuser");
    ColumnSet columns = new ColumnSet("systemuserid");
    queryByAttribute.AddAttributeValue("fullname", userName);

    EntityCollection retrieveUser = service.RetrieveMultiple(queryByAttribute);
    systemUserId = ((Entity)retrieveUser.Entities[0]).Id;
   }
   catch (Exception ex)
   {
    throw new Exception("Error: " + ex.Message);
   }
   return systemUserId;
 }

Calling above function to get admin id and impersonating admin user:

//need elevated permission service with impersonated user "admin"
 IOrganizationService elevatedpermissionService = serviceFactory.CreateOrganizationService(getUserId(service, "admin"));
 //use elevatedpermissionService to perform operatuion which normal calling user isn't allowed to do

This way we can get service object with the impersonated user and can just perform a specific set of operations with an impersonated object where normal user has insufficient permission.