Using WIF with Workflow Services

Windows Identity Foundation integrates with WCF at the host level (ServiceHost) and then various WIF extensibility points are invoked at different stages of WCF message processing pipeline. In this post, I will show how WIF can be integrated with Workflow Services to enable common security scenarios. Additional rich security scenarios can also be enabled by using activities which are currently part of WF Security Pack project.

Basic Walkthrough

Create a new WCF Workflow Service Application by choosing File -> New Project:

You would notice generated web.config is using simplified WCF 4.0 configuration. There are no explicit endpoint definitions rather service would get default endpoints at runtime.

<system.serviceModel>

</behavior>

</serviceBehaviors>

</behaviors>

</system.serviceModel>

A workflow service is a standard WCF service whose implementation is a workflow, so we should be able to integrate WIF using exactly the same techniques we know for code based WCF services.

Externalize the authentication to an STS

Inside Solution Explorer, right click on your workflow service project and select “Add STS Reference” option to launch FedUtil.exe.

On the Welcome Page, specify the Application URI and click next. On Security Token Service Page, select “Use an existing STS” option and specify the URL of the WS-Federation metadata document. For this example, I’m using AD FS 2.0 as the existing STS.

Leave the default value “Disable certificate chain validation” on next page as I’m using self-signed certificates.

On the “Security token encryption”, choose “Enable encryption” option and specify the private key certificate of your service.

Finish the wizard by choosing default values for the next two pages.

Wizard would generate all the configuration required to enable WIF on this Workflow Service. Lets briefly examine the generated configuration:

A new WIF related section is registered…

</configSections>

<microsoft.IdentityModel> configuration section is generated to externalize the authentication responsibility for this service to AD FS 2.0.

<microsoft.identityModel>

</audienceUris>

</trustedIssuers>

</issuerNameRegistry>

</service>

</microsoft.identityModel>

A new Service Behaviour is added to the default behaviour collection, which configures WIF on this Workflow Service at the host level (WorkflowServiceHost in this case)

</serviceCredentials>

</behavior>

</serviceBehaviors>

Default binding for the http scheme is changed to a wizard generated wsFederationHttpBinding. This enables all http based default endpoints to be configured to use this wsFederationHttpBinding.

</protocolMapping>

A new default configuration of ws2007FederationHttpBinding is also generated by the wizard based on the selection made in Wizard. This generated binding has an issuerMetadata element specifying the metadata URL of AD FS 2.0 which would be used by the clients to fetch all the endpoints supported by AD FS 2.0

</claimTypeRequirements>

</message>

</security>

</binding>

</ws2007FederationHttpBinding>

</bindings>

That’s it. Your claim-aware Workflow Service is ready now.

At this stage, clients can generate the required configuration by simply using “Add Service Reference” wizard which would generate config (endpoint addresses & bindings) for all the different endpoints supported by AD FS 2.0.

The main service endpoint would automatically be configured to acquire a token from AD FS 2.0 before calling the Workflow Service.

As AD FS 2.0 supports multiple endpoints, generated wsFederationHttpBinding simply picks the first endpoint returned by the AD FS 2.0. This first endpoint choice might not be appropriate in all scenarios and you can easily change it in the client config file.

<endpoint address="http://localhost:2534/Service1.xamlx" binding="customBinding"

bindingConfiguration="WS2007FederationHttpBinding_IService"

contract="ServiceReference1.IService" name="WS2007FederationHttpBinding_IService">

</identity>

</endpoint>

</client>

Claims Transformation

ClaimsAuthenticationManager can be used to perform claims-transformation exactly in the same way as in code based service.

public class SimpleClaimsAuthenticationManager:ClaimsAuthenticationManager

{

public override IClaimsPrincipal Authenticate(string resourceName, IClaimsPrincipal incomingPrincipal)

{

// Claims transformation...

return base.Authenticate(resourceName, incomingPrincipal);

}

This class can then be configured on the workflow service using following configuration. All other config except the highlighted line was automatically generated by FedUtil.exe.

</audienceUris>

</trustedIssuers>

</issuerNameRegistry>

</service>

Claims based Authorization

Similarly Claim-Based-Authorization can be enforced at the host level using a ClaimsAuthorizationManager.

public class SimpleClaimsAuthorizationManager:ClaimsAuthorizationManager

{

public override bool CheckAccess(AuthorizationContext context)

{

if (((IClaimsIdentity)context.Principal.Identity).Claims.Where(c=>

c.ClaimType== ClaimTypes.Upn &&

c.Value == "zam1d@bccoss.com").Count() ==0)

return false;

return true;

}

With above authorization manager plugged in, you can verify client is failing with “Access is denied” error.

Summary

Most of the WIF integration simply works with Workflow Services without any issues and is exactly the same as code based services. If you need to access claims inside your workflows or you want to implement more advance security scenarios such as

Fine grained control over token issuance and it’s usage
Claims-based delegation to other services

You can use WF Security Pack which provides additional activities and accompanying framework code to accomplish above mentioned security scenarios.