Using User Rights Impersonation

The delegation dilemma

In the past (and even more so today) in distributed deployments, there exists the increasingly common challenge of allowing a user to perform actions on a system under his/her security credentials whilst actually being connected to entirely a different system. ( i.e. logged on to MOSS, upload a doc and start a K2 process on another server running K2 under the same user account that uploaded the doc)

Scenario (NOT Using K2 Impersonation)

Bob is signed in and happily using a MOSS web site on the physical server “MOSS1”. The site is running under the App Pool Account of “MOSSUser”. When Bob opened the site, IIS is configured to automatically authenticate and Impersonate Bob using integrated Windows Authentication (NTLM). Now Bob opens a page which has some backend code embedded to display the logged in user and connect to K2 Server using SourceCode.Workflow.Client API with Integrated security and obtain the user’s worklist. The .NET code that’s busy executing underneath the covers is currently impersonating the identity of Bob and can display his login name on the screen just fine, the code then attempts a connection to the K2 Server using integrated security, the integrated connection fails and no worklist items are returned.

Why did the integrated connection to K2 Server fail if it works just fine on MOSS and even displays Bob’s name as the logged in user? Because the .NET code behind the page is not actually running locally on Bob’s machine where he is physically logged on, but running on the “MOSS1” server under the “MOSSUser” account that is currently impersonating “Bob” though an NTLM integrated security token and an impersonated token cannot perform integrated NTLM authentication. Only the original session where Bob is logged in can perform integrated authentication (this is also known as the double hop problem).

K2 Server’s Impersonation

K2 Server now has the ability to grant named user accounts explicit “impersonation” rights on a K2 Server level only. This allows for that named used account to connect to the K2Server using the SourceCode.Workflow.Client API and request the K2 Server treat that connection as if it was in fact made by completely a different user!

Scenario (Using K2 Impersonation):

Bob opens a page, the .NET code running as “MossUser” connects to K2Server requests the connection be impersonated as “Bob”. If the “MossUser” account was granted “Impersonation” rights by an Admin, that connection will from that point onward be treated as if was made by “Bob” himself.

All Workflow Actions will execute and be logged as if was “Bob”

Caveat: ONLY the named user accounts that were granted “impersonation” rights can actually impersonate and change the user context of a connection.

This code sample shows you how to open a specific user's worklist. In this simple example, only the workitem count is retrieved, however, this sample can easily be extended to action work items etc.

//References 
using SourceCode.Workflow.Client;   

							//Create a Connection to the Workflow Server 
Connection c = new Connection(); 

							c.Open("localhost"); 
  

							//Impersonate the specified user 
string sUserName = "K2:k2demo\bob"; 

							c.ImpersonateUser(sUserName);
  

							//Create the Worklist Criteria 
WorklistCriteria crit = new WorklistCriteria(); 

							crit.NoData = true; 
//Faster, doesn"t return the data for each item 

							crit.Platform = "ASP"; 
  

							//Open the Worklist and get the workitem count 
Worklist list = c.OpenWorklist(crit); 

							int workItemCount = list.TotalCount; 
        

							//Close the Connection 

							c.Close();