Workflow Security
Windows Workflow Foundation (WF) is integrated with several different technologies, such as Microsoft SQL Server and Windows Communication Foundation (WCF). Interacting with these technologies may introduce security issues into your workflow if done improperly.
Note
Workflows describe the order of execution and dependencies between short- or long-running tasks. As a code execution mechanism, only trusted code should be loaded and executed. Developers must ensure that only trusted workflows are used with applications using WF.
Persistence Security Concerns
Workflows that use a Delay activity and persistence need to be reactivated by a service. Windows AppFabric uses the Workflow Management Service (WMS) to reactivate workflows with expired timers. WMS creates a WorkflowServiceHost to host the reactivated workflow. If the WMS service is stopped, persisted workflows will not be reactivated when their timers expire.
Access to durable instancing should be protected against malicious entities external to the application domain. In addition, developers should ensure that malicious code can't be executed in the same application domain as the durable instancing code.
Durable instancing should not be run with elevated (Administrator) permissions.
Data being processed outside the application domain should be protected.
Applications that require security isolation should not share the same instance of the schema abstraction. Such applications should use different store providers, or store providers configured to use different store instantiations.
SQL Server Security Concerns
When large numbers of child activities, locations, bookmarks, host extensions, or scopes are used, or when bookmarks with very large payloads are used, memory can be exhausted, or undue amounts of database space can be allocated during persistence. This can be mitigated by using object-level and database-level security.
When using SqlWorkflowInstanceStore, the instance store must be secured.
Sensitive data in the instance store should be encrypted. For more information, see SQL Server Encryption.
Since the database connection string is often included in a configuration file, windows-level security (ACL) should be used to ensure that the configuration file (Web.Config usually) is secure, and that login and password information are not included in the connection string. Windows authentication should be used between the database and the web server instead.
Considerations for WorkflowServiceHost
Windows Communication Foundation (WCF) endpoints used in workflows should be secured. For more information, see WCF Security Overview.
Host-level authorization can be implemented by using ServiceAuthorizationManager. See How To: Create a Custom Authorization Manager for a Service for details.
The ServiceSecurityContext for the incoming message is also available from within workflow by accessing OperationContext.
WF Security Pack CTP
The Microsoft WF Security Pack community technology preview (CTP) 1 is a set of activities and their implementation based on Windows Workflow Foundation in .NET Framework 4 (WF 4) and Windows Identity Foundation (WIF). The Microsoft WF Security Pack CTP 1 contains both activities and their designers which illustrate how to easily enable various security-related scenarios using workflow, including:
Impersonating a client identity in the workflow
In-workflow authorization, such as PrincipalPermission and validation of Claims
Authenticated messaging using ClientCredentials specified in the workflow, such as username/password or a token retrieved from a Security Token Service (STS)
Flowing a client security token to a back-end service (claims-based delegation) using WS-Trust ActAs
