locked
WorkflowApplication and security context RRS feed

  • Question

  • I am launching workflows from a web application.  The problem I am running into is when WorkflowApplication.Run() is called it starts the workflow on a different thread - which does not have the security context of a logged in user.  The custom activities are calling business objects that demand the current context is logged in.  Is there an easy way to set the context of the thread it runs as?  I could spawn a new thread and set the context, but even then calling the .Run() method from within this spawned thread spawns yet another thread.  

    Thank you,
    John 

    [edit : I could make each of my custom activities check the context and set it to a predefined system account, but I would really like to make this automatic.  I have all my custom activities derive from a base activity, but developers must remember to call base.Execute(context) in order for it to work.]

    [edit 2: I found some stuff on SynchronizationContext but I do not understand if it is a bridge between the two threads or if it truly passes the context from a to b.  Without knowing this I cannot use it - if it is a bridge that keeps both threads around until they complete and someone writes a bad workflow that hangs, we would quickly burn through all our threads.]

    Thursday, April 28, 2011 3:07 PM

Answers

  • In case anyone is looking, found a very good description and answer here (you have to "fly" it over to the other thread):

    http://msdn.microsoft.com/en-us/magazine/gg598919.aspx

    WorkflowApplication This is a slightly more capable host but still supports only a single instance. This host executes workflow using the IO threads from the CLR ThreadPool. The security context of a calling thread isn’t copied to the workflow thread, so even if the workflow client is impersonating, the WF thread—which is executing the activities—won’t be impersonating. The security context of the caller can be flown to the WF thread using a custom Synchronization context that would forward the call on the same incoming Async thread, similar to the Synchronization context used by the WorkflowInvoker:

    1. public class MySyncContext : SynchronizationContext
    2. {
    3.   public override void Post(SendOrPostCallback d, object state)
    4.   {
    5.     d(state);
    6.   }
    7. }

    And to use it:

    WorkflowApplication workflowApplication = new WorkflowApplication(new...
    workflowApplication.SynchronizationContext = new MySyncContext();
    

    And thank you to this post for sending me in the right direction:

     


     

    • Marked as answer by John Hennesey Thursday, April 28, 2011 5:19 PM
    Thursday, April 28, 2011 5:19 PM
  • >[edit 2: I found some stuff on SynchronizationContext but I do not understand if it is a bridge between the two threads or if it truly passes the context from a to b. Without knowing this I cannot use it - if it is a bridge that keeps both threads around until they complete and someone writes a bad workflow that hangs, we would quickly burn through all our threads.]

    You probably got the answer from that article, but SynchronizationContext is basically a 'request dispatcher' which decides the details of how some work requests get executed. That can mean deciding what thread they run on, it can also mean things like setting up other 'context' available to the work item (OperationContext, RequestContext etc?). Since SynchronizationContext is subclassable the details of exactly how the work happens are up to the particular implementation.

    Tim

    • Marked as answer by John Hennesey Friday, April 29, 2011 12:49 PM
    Thursday, April 28, 2011 11:56 PM

All replies

  • In case anyone is looking, found a very good description and answer here (you have to "fly" it over to the other thread):

    http://msdn.microsoft.com/en-us/magazine/gg598919.aspx

    WorkflowApplication This is a slightly more capable host but still supports only a single instance. This host executes workflow using the IO threads from the CLR ThreadPool. The security context of a calling thread isn’t copied to the workflow thread, so even if the workflow client is impersonating, the WF thread—which is executing the activities—won’t be impersonating. The security context of the caller can be flown to the WF thread using a custom Synchronization context that would forward the call on the same incoming Async thread, similar to the Synchronization context used by the WorkflowInvoker:

    1. public class MySyncContext : SynchronizationContext
    2. {
    3.   public override void Post(SendOrPostCallback d, object state)
    4.   {
    5.     d(state);
    6.   }
    7. }

    And to use it:

    WorkflowApplication workflowApplication = new WorkflowApplication(new...
    workflowApplication.SynchronizationContext = new MySyncContext();
    

    And thank you to this post for sending me in the right direction:

     


     

    • Marked as answer by John Hennesey Thursday, April 28, 2011 5:19 PM
    Thursday, April 28, 2011 5:19 PM
  • >[edit 2: I found some stuff on SynchronizationContext but I do not understand if it is a bridge between the two threads or if it truly passes the context from a to b. Without knowing this I cannot use it - if it is a bridge that keeps both threads around until they complete and someone writes a bad workflow that hangs, we would quickly burn through all our threads.]

    You probably got the answer from that article, but SynchronizationContext is basically a 'request dispatcher' which decides the details of how some work requests get executed. That can mean deciding what thread they run on, it can also mean things like setting up other 'context' available to the work item (OperationContext, RequestContext etc?). Since SynchronizationContext is subclassable the details of exactly how the work happens are up to the particular implementation.

    Tim

    • Marked as answer by John Hennesey Friday, April 29, 2011 12:49 PM
    Thursday, April 28, 2011 11:56 PM