Windows Server Appfabric Hosting

Hands-On Lab

Windows Server AppFabric Hosting:

Lab 5 - Securing WF Services

Lab version:1.0.0

Last updated:12/15/2018

Contents

Overview

Starting Materials

Exercise 1: Securing a Workflow Service

Task 1 – Adding a reference to Microsoft.Activities.SecurityPack.dll

Task 2 – Adding a PrincipalPermissionScope to the FlowChart

Summary

Overview

Security in the context of Workflow Services revolves around authorizing callers to be able to execute operations, as well as being able to attach an identity to an outgoing call made by a workflow service to another service. This functionality is present in the framework as is exposed by activities in the Workflow Services Security Pack, and a library provided by Microsoft that is released separately from the .NET Framework. These activities can be used to secure using Windows, Username/Password and claims based credentials.

In this lab, you will use the PrincipalPermissionScope activity to restrict access to the ProcessLabel operation of the LabelingService. In the FourthCoffee scenario, we only want new instances of the resource intensive LabelingService to be started by the OrderFulfillmentService. One way to approach this is by restricting access to callers who have a Windows Identity of the account that is executing the OrderFulfillmentService. Because the OrderFullfillmentService runs in IIS, it is the identity of the AppPool that executes the OrderFullfilmentService is what we will grant. By default the app pool used is the Default App Pool and it has the Windows identity of “IIS AppPool\DefaultAppPool”. In this lab we show how to perform this authorization within the LabelingService.

Objectives

In this lab, you will become familiar with:

The Workflow Services Security Pack
Configuring the PrincipalPermissionScope activity to examine Windows principals

Setup

You must perform the following steps to prepare your computer for this lab:

Complete the Development Environment Setup lab.
Read through the Fourth Coffee Solution Overview to understand the solution that will be implemented in these labs.
To simplify the process of registering the numerous Fourth Coffee applications with IIS, we have provided a utility called LabStarter that you should run as the first step in any lab.
To use it, run LabStarter.exe from the %InstallFolder%\Assets directory and click the button corresponding to the Lab exercise you wish to open. This will perform the requisite configuration and then open the desired solution in Visual Studio for you automatically.

Exercises

This Hands-On Lab comprises the following exercise:

Exercise 1 – Securing a Workflow Service

Estimated time to complete this lab: 30minutes.

Starting Materials

Use the LabStarter as described in the Setup section to begin this lab.

Note:Inside each exercise folder, you will find anend folder containing a solution with the completed lab exercise.

Exercise 1: Securing a Workflow Service

In this exercise you will secure the ProcessLabel operation of the LabelingService using the PrincipalPermissionScope activity.

Task 1 – Adding a reference to Microsoft.Activities.SecurityPack.dll

Before you can use the PrincipalPermissionScope activity, you need to add a reference to its assembly. The assembly and its related designer assembly have been provided for you in the solution under the Reference Assemblies folder.

Open the starter solution for this exercise as described in the Starting Materials section.
Open the LabelingService.xamlx in the LabelingService project using the Workflow Designer.
Right click the Toolbox, and select Choose Items....
In the dialog that appears (set to the System.Activities components tab automatically) click the Browse button.
Browse to the solution %InstallFolder%\Assets\Reference Assemblies folder and select Microsoft.Activities.SecurityPack.dll and click OK.
The dialog should look as follows, with all of the activities of the security pack selected.
Click OK to add the activities to the Toolbox. The activities should appear as follows:

Task 2 – Adding a PrincipalPermissionScope to the FlowChart

Next you will add the PrincipalPermissionScope activity to the FlowChart and use it to secure the ProcessLabel operation defined by the ReceiveRequest / SendReply activity pair at the top of the FlowChart.

Drag and drop the PrincipalPermissionScope activity near the top of the workflow as shown.
Double click the PrincipalPermissionScope to drill down so you can see it completely. The PrincipalPermissionScope activity has three main items you need to consider in order to secure an operation. On the activity’s design surface, the Name property is where you specify the username which the caller must have. The Role property allows you to specify the Role to which the user belongs. The body (where it says “Please drop an activity here” is where you must place an Receive operations you want to secure by username or role.

Note: In order to be able to use Windows identities with workflow services, you must use a binding that supports them (as has already been done for you in this lab). The basicHttpContext binding used by default for SOAP services using HTTP protocol (as used by the other services in Fourth Coffee) is not sufficient because it does not pass along the client identity. The binding to use is the wsHttpContextBinding, and using it on the LabelingService is easy because we can change the default binding used for the service simply by changing which binding the HTTP protocol defaults to using by defining a protocolMapping section in the web.config:

Click the Workflow Service text in the breadcrumb at the top left of the designer to return to the FlowChart view.
Change the name of the PrincipalPermissionScope activity to Secure ProcessLabel.
To secure the ProcessLabel activity, we will need move it within the body of the PrincipalPermissionScope activity.
Since we cannot copy a SendReply activity, we will delete it first and recreate it after situating the Receive activity. Select SendReplyToProcessLabel Request, and delete it.
Right click the ProcessLabel Request activity and select Cut.
Double click the Secure ProcessLabel activity. Within the body, drag and drop a Sequence activity.
Within the newly added sequence, paste the ProcessLabel Request activity.
To re-create the reply, right click the ProcessLabel Request activity and choose Create SendReply.
Select the Secure ProcessLabel activity and for the Name field enter "IIS AppPool\DefaultAppPool" including the quotes. The Secure ProcessLabel should appear as follows:
Return to the flowchart and connect Secure ProcessLabel between Start and the LabelGenerator activity.
Now callers of the ProcessLabel operation can only be those with the username of DefaultAppPool. It is important to note, that we have only secured the ProcessLabel operation- the other operations (ApproveProof and CleanupProof) are not surround by a PrincipalPermissionScope and therefore are note secured (though they could be).
Build the solution.

Exercise 1 Verification

In order to verify that you have correctly performed all steps of exercise 1, proceed as follows:

Verification 1

In this verification, you will run the LabelingService twice: once directly from the TestClient, and a second time indirectly from the TestClient by invoking the OrderFulfillmentService which will invoke it. Only the second time should succeed, because it is the one with the appropriate identity.

Run the Test Client, and choose option 4.
You should get an exception, with the message Access is Denied as follows:
Run the Test Client again and choose Option 1, answering Y to both prompts, and pressing Enter to approve the proof. The workflow should run to completion successfully as shown:

Summary

In this lab you have secured a workflow service simply by adding an activity which encapsulates the operations you want secured, and configuring that activity. The PrincipalPermissionScope activity we used to do this is part of the Microsoft Workflow Services Security Pack, and is just one of many activities that assist with security related tasks within workflow services.