Zulfiqar's weblog

Architecture, security & random .Net

Integrating WIF with WF 4.0 and AppFabric

Posted by zamd on May 18, 2010

WIF is framework to claim-enable ASP.net applications and WCF services. WF 4.0 introduced a new paradigm for developing services (known as Workflow Services), whose implementation is based on workflow. Windows Server AppFabric provides the hosting, management & monitoring capabilities for services with a primary focus on workflow services.

WIF integration with Workflow services can be seen at couple of different scopes.

1. Claims-Enabled Workflow Service

As workflow services are standard WCF services, WIF can easily be enabled at the WCF layer using the standard configuration based approach documented in MSDN. This would claims-enable your workflow services and you can use various WIF’s extensions (code-based) for claims-transformation (ClaimsAuthenticationManager) and claims-based authorization (ClaimsAuthorizationManager).

2. Workflow Services calling other Claims-Enabled Services

WF 4.0 provides messaging activities to call other services from workflows. In most cases, Claims-Enabled services require a token from an STS. In a non-WF world, you can either use wsFederationHttpBinding or the new fine grained WIF API (WSTrustChannelFactory) to do this (you can use IssuedSecurityTokenProvider directly). The wsFederationHttpBinding approach kind of works (transparently) in Workflow services world as well but could be quite expensive in terms of performance. See my post on messaging activities for additional details. The wsFederationHttpBinding approach is also not suitable for scenarios, where you need fine-grained control of issued tokens or you want to use issued token in long-running scenarios without re-acquiring them.

3. WIF in middle-tier Workflow Services

WIF enables claims-based-delegation using then ActAs/OnBehalfOf element of WS-Trust protocol. In code-based services, you can access the incoming token in the middle-tier service and then use this when acquiring a SAML token to call a backend service. With this model, the backend service can see all the identities involved in the call chain. Claims-based delegation is not easily possible in workflow services when using wsFederationHttpBinding.

1 & 2 be greatly enhanced by introducing custom activities which can decouple token acquisition from its use; much like activity counterpart of WIF’s WSTrustChannelFactory API.


In above diagram InitializeSamlSecurityToken custom activity encapsulate the functionality of acquiring a token from a STS using the WS-Trust protocol. Internally it uses the standard correlated Request-Reply pair configured for WS-Trust contract. I’ll talk more about TokenFlowScope in a future post but here it enables the Ping activity to use the acquired token when calling a service which requires Saml token. I have attached complete solution with post (STS, Test Service & a Test Client)which also includes alpha drop of WFSP binaries as well. Feel free to download and experiment and let me know your thoughts.

9 Responses to “Integrating WIF with WF 4.0 and AppFabric”

  1. scott_m said

    Great post! In a future post, will you please show how to secure your WF service (using W.I.F) from un-authenticated external callers? In my case, I would like to have an asp.net mvc client make calls into my WF Service. My asp.net MVC client already has an IClaimsIdentity as the current thread identity. Ideally it would be nice for the identity to flow from the ASP.NET MVC client to my WF Service for authentication / authorization / auditing purposes. For me, it was not very clear from the official W.I.F. / W.F. docs on how to do this.

  2. […] Integrating WIF with WF 4.0 and AppFabric […]

  3. scott_m said

    Does WF or WFSP provide a good way to preserve the thread identity once a wf instance has been de-hydrated and then later re-hydrated? In ASP.NET world we have S.A.M. to handle thread identity state. Was curious how this will work in WF / WFSP.


  4. scott mcfadden said

    In my scenario, the Thread.CurrentPrincipal.Identity would be be a ClaimsIdentity instance representing a custom user stored in sql (not an Active Directory user). Guess I could look at storing a serialized version of the current token in the wf instance. After re-hydration, I would then have to de-serialze the token (although the token could possibly be expired at this point making this difficult). Another un-appealing but possible option is to somehow pass along the user credentials in the wf making it easier to obtain a new token after re-hydration.

  5. zamd said

    WFSP already support token persistence/loading for long running scenarios. For example, if your workflow has a acquried a token and enlisted it with a handle (SecurityTokenHandle), now when it persists, WFSP will also persist the Saml token and will reload the token when workflow reloads. As you mentioned, at this stage token can be expried, you would have to handle this in your workflow logic. WFSP doesn’t however set the identity on the Thread but this can be done easily.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: