Compartilhar via

Prescriptive Security Guidance for Workflow Services

  • Artigo

The following is a set of security guidelines to use when creating and deploying Workflow Services.

  • Use signed and encrypted messages when communicating between client and service, or service and persistence database, to prevent malicious users from reading or modifying data that is sent over the network. For more information about message protection levels, see Understanding Protection Level.

  • Use principal permissions and claims instead of conversation IDs or instance IDs for authentication or authorization. For more information about using principal permissions and claims, see How to: Restrict Access With the PrincipalPermissionAttribute.

  • Use ACLs and signed assemblies from trusted sources to prevent malicious users from impersonating your workflow service.

  • Follow the guidelines on obfuscation to make sure malicious users cannot disassemble your workflow service assembly and read the binding information or statically defined property values (or both) within it.

  • Lock down access to your persistence database and perform database auditing to review for any access violations. Use ACLs and file auditing if you are storing serialized data in the file system.

  • Protect any configuration files with ACLs and optionally encrypt the connection string held in the connectionStrings element to prevent malicious users from discovering the connection string you use to connect to your database.

  • Consider having a database-based file using ASP.NET VirtualPathProvider instead of deploying actual workflow markup and .rules file in IIS.

  • Present a minimal set of permissions to the process that is hosting the workflow service and avoid running the process (IIS App pool) with administrative privileges.

  • Ensure that third-party components, such as custom activities, custom hosting services, and custom dispatch components, are all trusted and conform to the overall security theme of your application. These components have access to sensitive resources like the channel factory cache, where malicious code could replace channels used by the SendActivity activity.

  • Use the MaxFieldLength registry key for HTTP.sys to throttle the size of the HTTP headers that your service receives from clients. This will prevent malicious users from attaching a large HTTP context cookie to any messages sent to the server. For more information about setting this registry key, see HTTP.sys registry settings for IIS.

  • Use EncryptandSign or the Https transport protocol to prevent malicious users from reading a confidential context header or cookie information in transit between client and service.

  • Be aware that channels can be created and destroyed across the lifetime of sessions based on a context binding. Consequently, when using a context binding, identity can change during the lifetime of the session.

See Also

Other Resources

Security Considerations for Workflow Services and Durable Services