Share via

Security Configuration for Persistence Stores

  • Article

The access to the SQL Server persistence database is secured through the following SQL Server roles:

  • InstanceStoreUsers. Members of this role can load/save workflow instances from/to the instance store. The application that uses WorkflowServiceHost or WorkflowApplication to host services and uses SqlWorkflowInstanceStore for persistence should run under an identity that is a member of this role.

  • InstanceStoreObservers. Members of this role can query the instance store. The application that uses WorkflowServiceHost or WorkflowApplication to host services and uses SqlWorkflowInstanceStore for persistence should run under an identity that is a member of this role.

  • WorkflowAdministrators. Members of this role can enqueue (add) control commands to the command queue in the instance store.

  • WorkflowActivationUsers. Members of this role can query the instance store for activatable workflow instances. The Workflow Management Service (WMS) must run under an identity that is a member of this role.

  • WorkflowManagementServiceUsers. Members of this role can dequeue (retrieve) control commands from the command queue in the instance store. The WMS must run under an identity that is a member of this role.

Access to the SQL persistence store is granted on a per-store basis. A user who has access to instances of a workflow service stored in an instance store has access to all instances including instances of a different workflow service in the store. To prevent users who have access to instances of one service from accessing instances of another service, you must make sure that separate instance stores are used for these two services.

For example, suppose Service1 runs under User1 identity, Reader1 can query for instances of Service1, and Admin1 can control instances of Service1. And Service 2 runs under User2 identity, Reader2 can query for instances of Service2, and Admini2 can control instances of Service2. To prevent User1/Reader1/Admin1 from loading/querying/controlling instances of Service2 and User2/Reader2/Admin2 from loading/querying/controlling instances of Service1 all instances of Service1 must be stored in an instance store Store1 and all instances of Service2 must be stored in an instance store Store2.

In this scenario, a user has to add the following users or Windows groups to these roles:

  • Add User1 to InstanceStoreUsers role of Store1 database. Alternatively, add User1 to a Windows group UserGroup1 and add UserGroup1 to InstanceStoreUsers role of Store1 database.

  • Add Reader1 or ReaderGroup1, a Windows group that Reader1 is a member of, to InstanceStoreObservers role of Store1 database.

  • Add Admin1 or AdminGroup1, a Windows group that Admin1 is a member of, to WorkflowAdminstrators role of Store1 database.

  • Add User2 or UserGroup2, a Windows group that User2 is a member of, to InstanceStoreUsers role of Store2 database.

  • Add Reader2 or ReaderGroup2, a Windows group that Reader2 is a member of, to InstanceStoreObservers role of Store2 database.

  • Add Admin2 or AdminGroup2, a Windows group that Admin2 is a member of, to WorkflowAdministrators role of Store2 database.

  • Add the security identifier (SID) of the WMS to the Windows groups AdminGroup1 and AdminGroup2.

Persistence Security Example

To increase security more, you can run multiple instances of the WMS. For example, suppose you have two instances WMS1 and WMS2 of the Workflow Management Service running and both instances run under the BUILTIN\Local Services account. Assume that WMS1 is assigned the Security Identifier WMS-SID1, and WMS2 is assigned the Security Identifier WMS-SID2. In this case, you have to follow these steps instead of performing the last step in the preceding list of steps:

  • Add WMS-SID1 to the Windows group WMSGroup1 and add WMSGroup1 to WorkflowActivationUsers and WorkflowManagementServiceUsers of Store1 database.

  • Add WMS-SID2 to the Windows Group WMSGroup2 and add WMSGroup2 to WorkflowActivationUsers and WorkflowManagementServiceUsers of Store2 database.

Instance Control Endpoint Authorization

You should change the authorization of Instance Control Endpoints (ICEs) of all services that persist to Store1 to WMSGroup1 for the scenario described in previous section. Similarly, you should change the authorization of ICEs of all services that persist to Store2 to WMSGroup2. The following example shows how to secure access to an ICE by using a configuration file.

<configuration>
    <system.serviceModel>
        <behaviors>
            <serviceBehaviors>
                <behavior name="myServiceBehavior">
                    <workflowInstanceManagement authorizedWindowsGroup="WMSGroup1" />
                </behavior>
            </serviceBehaviors >
        </behaviors>
    </system.serviceModel>
</configuration>

Service Management Endpoint Authorization

You should change authorization of Service Management Endpoints (SMEs) of all services that persist to Store1 to WMSGroup1 for the scenario described at the beginning of the topic. Similarly, you should change the authorization of SMEs of all services that persist to Store2 to WMSGroup2. The following example shows how to secure access to an SME by using a configuration file.

<configuration>
    <microsoft.applicationServer>
        <hosting>
            <serviceManagement enabled="true" authorizedWindowsGroup="WMSGroup1" endpointConfiguration="ServiceManagementNetPipeEndpoint" />
        </hosting>
    </microsoft.applicationServer>
</configuration>

Workflow Management Service Configuration

You should configure WMS1 to monitor Store1 and WMS2 to monitor Store2 for the scenario described at the beginning of the topic. To do so, modify the Workflow Management Service configuration section in the root Web.config file as shown in the following sample configuration.

<configuration>
    <microsoft.applicationServer>
        <persistence>
            <workflowManagement>
                <workflowManagementServiceInstances>
                    <workflowManagementServiceInstance name="WMS1">
                        <instanceStores>
                            <instanceStore name="Store1" location="[root, SiteName or VPath]" />
                        </instanceStores>
                    </workflowManagementServiceInstance>
                    <workflowManagementServiceInstance name="WMS2">
                        <instanceStores>
                            <instanceStore name="Store2" location="[root, SiteName or VPath]" />
                        </instanceStores>
                    </workflowManagementServiceInstance>
                </workflowManagementServiceInstances>
            </workflowManagement>
        </persistence>
    </microsoft.applicationServer>
</configuration>

Windows Server AppFabric Configuration Wizard

The AppFabric Configuration Wizard lets you associate Windows groups to three types of users: Administrators, Readers, and Users. By default, the Windows groups AS_Administrators, AS_Observers, and IIS_USRS are associated with Administrators, Readers, and Users respectively. The wizard adds AS_Administrators to the InstanceStoreObservers, WorkflowActivationUsers, WorkflowAdministrators, and WorkflowManagementServiceUsers roles in SQL Server, adds AS_Observers to the InstanceStoreObservers role, and adds IIS_USRS to the InstanceStoreUsers role.

The wizard sets the value of the authorizedWindowsGroup attribute of the workflowInstanceManagement element and the value of the authorizedWindowsGroup attribute of the serviceManagement element to AS_Administrators.