Security Considerations for Workflow-Enabled Applications
When you create workflow hosts and services, you should consider the following regarding security:
Extensively test hosting services that are authored cross-team or cross-company before you use them as part of the host.
The host must secure all data stores for workflow instances and tracking by associating them with an access control list (ACL). An ACL is a list of security protections that applies to an object.
The host configuration file should be associated with an access control list (ACL) to prevent tampering.
The host must trust the workflows that run by using the workflow runtime.
The host should authenticate the security principal.
The host should secure the databases used for timers and state persistence.
The host must trust the workflow that is being tracked.
Passing in a null System.Security.Principal.WindowsIdentity object to RaiseEvent methods corresponds to anonymous access with no role check.
Any dynamic changes to WorkflowRoleCollection should be guarded by appropriate access checks at the host level.
SQL connection strings should be specified individually or at one central location.
SQL scripts are part of configuration but do not run at installation time.
Integrated SQL server security should be used for the default SQL tracking service.
Databases, configuration files, and activity and workflow assemblies should be secured by the hosting environment.
Data stores for messages, queues, and workflow instance data should be secured by the host.
Default tracking services, such as the SQL tracking services should have complete access to the tracking database.
Tracking services are responsible for moving data events pushed to them to their corresponding data stores.
The host must set appropriate access controls on profiles that are stored in XML format or trust the profile object passed to the host.