locked
What Identity is Workflow Service 4.0 using? RRS feed

  • Question

  • Hello

    I am struggling to understand which windoes identity my workflow is running under.

    I have a simple test 4.0 workflow (VS2010 RC) using a ReceiveandSendyReply message which is using persistance and monitoring via AppFabric (Beta 2). The test workflow has a simple 20 sec delay and then writes a file to a directory in order to establish that the workflow has worked properly, which it does every time. The reply message passes back the windows identity being used within the workflow by using sending System.Security.Principal.WindowsIdentity.GetCurrent.Name.

    The calling client is a web app running impersonation correctly (tested and confirmed) via the following web.config section <identity impersonate="true" userName="machine\user" password="password" />.

    I have anonymous and windows authentication turned on for the service. When I run the workflow service using a web.config that has  <identity impersonate="true" /> the returned identity name is blank and AppFabric shows persistance records but no monitoring records. When I use the <identity impersonate="true" userName="machine\user" password="password" /> setting, the returned identity is the IIS (7) App Pool that the service is running under (not the actual user I am using in impersonation) and monitoring records are created.

    When I run the service with the first configuration, my SQL Server event log tells me that the user has no rights to open the monitoring database, therefore no monitoring records are written (makes sense), and my impersonated user does have rights so therefore they write to DB when using the second configuration.

    What I can't understand is why the service return is telling me that the app pool is the current identity, but all other evidence tells me that the impersonation user is the identity. In a further test, when the workflow service is asked to make a direct call to a SQL database using integrated security, it fails because the app pool does not have rights.

    Confused.
    • Moved by Andrew_Zhu Wednesday, March 24, 2010 9:38 AM (From:Windows Workflow Foundation)
    Thursday, March 18, 2010 1:25 AM

Answers

  • Hi Paul,

    I want to clarify what Ameen pointed out.  By default, we don't take the identity off of the incoming message and impersonate in the WF thread.  It is possible to do this in WF4 today, although it's not that intuitive.  We are working on making that much easier, and hope to have a good solution for you to use shortly.  Take a look at this blog post for some introductory information:

    http://www.zamd.net/2010/02/23/IntroducingWorkflowSecurityPack.aspx

    We hope to have additional details to give on this activity pack soon.  In the meantime, you can implement this yourself in the following way:

    Write a custom Scope activity (in the pack, we call it "ImpersonationScope").  This activity will allow other activities to be dropped inside of it, in particular your Receive and SendReply and any other activities that you want to be part of the impersonation.  In a separate class, implement a new ExecutionProperty that implements IReceiveMessageCallback and pulls the identity out of the message using OperationContext.ServiceSecurityContext.  As part of this ExecutionProperty, also make sure to implement the logic for SetupWorkflowThread, where you will use the identity to call impersonate on the thread.  In the Execute method of your Scope activity, add this ExecutionProperty to the execution context.

    Hope that helps.  In the absence of doing all of this yourself, as I mentioned, we are working on getting a solution out there for you to use.

    Thanks,

    -- Dave

    Thursday, March 25, 2010 11:29 PM

All replies

  • Hi Paul,

    I beleive unfortunately Workflow Services in 4.0, don't support identity yet.

    Ameen.

    • Proposed as answer by AmeenEt Thursday, March 25, 2010 11:59 PM
    Thursday, March 25, 2010 3:59 AM
  • Hi Paul,

    I want to clarify what Ameen pointed out.  By default, we don't take the identity off of the incoming message and impersonate in the WF thread.  It is possible to do this in WF4 today, although it's not that intuitive.  We are working on making that much easier, and hope to have a good solution for you to use shortly.  Take a look at this blog post for some introductory information:

    http://www.zamd.net/2010/02/23/IntroducingWorkflowSecurityPack.aspx

    We hope to have additional details to give on this activity pack soon.  In the meantime, you can implement this yourself in the following way:

    Write a custom Scope activity (in the pack, we call it "ImpersonationScope").  This activity will allow other activities to be dropped inside of it, in particular your Receive and SendReply and any other activities that you want to be part of the impersonation.  In a separate class, implement a new ExecutionProperty that implements IReceiveMessageCallback and pulls the identity out of the message using OperationContext.ServiceSecurityContext.  As part of this ExecutionProperty, also make sure to implement the logic for SetupWorkflowThread, where you will use the identity to call impersonate on the thread.  In the Execute method of your Scope activity, add this ExecutionProperty to the execution context.

    Hope that helps.  In the absence of doing all of this yourself, as I mentioned, we are working on getting a solution out there for you to use.

    Thanks,

    -- Dave

    Thursday, March 25, 2010 11:29 PM
  • Dave,

     

    The link is not current to the Security Pack, the new one is here.

     

    http://zamd.net/2010/02/23/introducing-workflow-security-pack/

     

    I was wondering, if identity isn't working yet in WF4, what is the best practice for making sure this Workflow Hosted Security are secure?   Should we use our own security? How close is this security pack to production ready?


    Morgan
    Wednesday, May 19, 2010 5:31 PM