Securing Workflow Services with Windows Identity Foundation, Part 2

Download the code here

This article is part two of a two-part series showing how to leverage Windows Identity Foundation (WIF) to secure workflow services. (See "Securing Workflow Services with Windows Identity Foundation, Part 1".) In this article, we add more detail to our treatment of building services secured by WIF. We modify the scenario presented in part one to replace the development-time only Security Token Service (STS) with the production-ready Active Directory Federation Services (ADFS) 2.0. In addition to explaining how to switch STSs, we also explore the challenges that surface when you are dealing with identity issues that result from services calling other services. To this end, we present the Claims to Windows Token Service (C2WTS). C2WTS can help you convert an incoming claim that contains a user principal name (UPN) value into a Windows Identity that you can impersonate and use to make calls to resources, such as a SQL Server, that are secured with Windows Integrated Security.

The Scenario
In this article, we will continue with the WidgetsNow! scenario whereby employees within the Contoso network are able to place orders for widgets using the WidgetsNow! client application. This application launches the WidgetsNow! Workflow Service, which is designed to simulate an order fulfillment workflow. For this article, we modify the WidgetsNow! Workflow Service to call out to a new inventory workflow service. This latter service is responsible for reserving items from the inventory database. Figure 1 shows the enhanced architecture.

 

 
While we add a new service to the downstream mix, the authentication and authorization rules we used previously are maintained as we migrate to using ADFS 2.0 as the STS. To recap, the rules are:

 

• Only members of the SeniorManagers Windows group can expedite orders.
• Only users in the Contoso domain can place orders.

Starting Out
The Download the Code link at the top of this article contains a link where you can download the project files both in the current and envisioned states. We will begin with the solution in the current state, the final state of part one, which leverages the customized Visual Studio STS template. And we will illustrate the key steps in converting it to use ADFS 2.0. See part one for the details of the workflow implementation.

Implementation
Figure 2 illustrates our approach to implementing the requirements previously described by leveraging WIF, ADFS 2.0, and C2WTS.

 

 
Let's step through the communications shown in the diagram, and then we'll drill into implementation.

 

1. The Windows Presentation Foundation (WPF) client application has a reference to the WidgetsNow! Workflow Service, and from that the client knows that it will need to present a security token containing a name claim and a CanExpediteOrders claim in order to be able to call the Service. It must acquire the security token from the ADFS 2.0 STS by presenting its Windows username and groups claims.
2. The ADFS 2.0 STS accepts the security token containing the Windows-based claims, which it validates and converts to a Name claim. In addition, if the user is a member of the SeniorManagers Security Group in Active Directory, it also issues a claim containing a CanExpediteOrders claim with a value of true. These two claims are sent back to the client in a single token.
3. Now that the client has the required token, the client can call the service by invoking the PlaceOrder operation and presenting the token.
4. A custom ClaimsAuthorizationManager examines the claims presented in the token. If PlaceOrder is the operation being invoked, the username presented is checked for belonging to the Contoso domain. If it does, then the request is allowed to flow through to the workflow service. If it does not, then the client gets an Access denied error.
5. The request makes it to the WidgetsNow! Workflow Service for processing and possibly for additional authorization. In most cases, this results in a successful call with the desired value being returned. In the case of a call to PlaceOrder, if the user elected to expedite the order, the CanExpediteOrder claim is examined for a true value. If there is no true value, a fault exception informs the client that he or she is not allowed to place an expedited order.
6. As a prerequisite to calling the Inventory service, the WidgetsNow! service calls ADFS and presents the Windows credentials of the account running the service. Then, ADFS returns a new token containing the Kerberos UPN for that account.
7. The WidgetsNow! service calls the ReserveOrder operation on the Inventory service, including the token just acquired in the call.
8. A SecurityTokenHandler intercepts the UPN token and passes it to the C2WTS, which converts the incoming Claims Identity to a Windows Identity.
9. During its execution, the Inventory service impersonates this Windows Identity when making a call to a local SQL Server database secured using Windows Integrated credentials.