I came across an issue with the combination of WCF, WF, WIF and AppFabric in December that had me a little worried. The issue was how to get the identity of the user calling a WCF service inside a WorkflowServiceHost workflow when using WIF to manage security and AppFabric for WF persistence.

The WIF documentation says the following:

As a note, when WIF is enabled inside WCF, the WCF ServiceSecurityContext does not work for obtaining the caller’s identity and claims; the application code must use the IClaimsPrincipal to access the caller’s information. You can obtain the IClaimsPrincipal instance using Thread.CurrentPrincipal. This is available for every authentication type as soon as WIF is enabled for the WCF application.

I had been developing my service application using Thread.CurrentPrincipal based on this information. Everything was fine until I started using WF persistence. Unfortunately enabling persistence (via AppFabric) had the affect of wiping out Thread.CurrentPrincipal.

The TypePresenter control is the UI that the WF designer displays for selecting a type. It is often seen on generics based activities and the InvokeMethod activity.

This drop down list provides some common types and includes some of the types already found in the current activity context. Selecting “Browse for Types …” allows for all referenced types to be searched in a dialog.

Sometimes you don’t want the TypePresenter to provide every available type. The TypePresenter has a great feature that allows you to restrict the types it displays in this list and the associated “Browse for Types …” dialog. This is done by providing a Func<Type, Boolean> reference on the TypePresenter’s Filter property.

I have written a simple WF4 activity that validates a WIF IClaimsIdentity has certain claims attached to it for a specific claim value. I wrote several unit tests for this activity to validate the implementation. The basic logic is to select a subset of claims that have a specified claim value using Where(). I then fall into a flow chart that validates whether there are any claims (Any() == false) and then whether there is only one claim (First() with a Count()) of a specified claim type that will not be accepted.

Almost all of the tests failed with the following error:

My presentation of Not a WIF of federation is done and dusted for CodeCampOz 2010. I got a little cut short by the early arrival of pizza’s so there are a couple of things I had to skip.

One of the important points I was not able to make is that the demo code displayed is not production ready. It’s not that the code itself is flawed rather that the certificates used were development certificates. It is important to secure your WIF implementation with production quality certificates in order to ensure that system security is maintained.

Identity delegation was the last demo that I presented. I didn’t get the opportunity to show the code that was changed in the STS application to make this work. The code in the STS project had not be changed up until this point. The GetOutputClaimsIdentity method of the CustomSecurityTokenService class simply returned a new ClaimsIdentity created from the provided principal. The delegated identity scenario needs to explicitly cater for the ActAs scenario by attaching the delegating identity to the Actor property on the delegated identity being returned.

I posted yesterday about how to get content correlation of multiple WCF service operations to work with hosted WF services. The request and reply data of the WCF service operations is the basis of content correlation. It is therefore quite easy for a client application to send data to the service that does not satisfy business validation.

If the invalid data sent to the service operation participates in content correlation then the WorkflowServiceHost will not identify a WF instance. This unfortunately means that business validation of this data will not run in the workflow as no workflow instance is executing. The result is that the client will receive the following very unfriendly FaultException (assuming no exception shielding is in place).

Content correlation in hosted WF services seems daunting but is surprisingly simple to use with the available designer support. Content correlation uses data from the workflow to link (correlate) multiple WCF service operations to the same hosted workflow instance. Content correlation is different to context correlation where WCF communication down at the binding level handles correlation. There is unfortunately a lack of detailed examples available on how to get content correlation to work. This post aims to fill that gap.

I have an account registration scenario where the first service operation is to request a new account. The request needs to provide a first name, last name, email address and a password. The register account workflow will run some validation logic and then send an email to the email address with a link back to a website for confirmation.

There have been a couple of really good posts recently about SSL and certificates over on blogs.msdn.com. Check them out.

Planky - Crypto Primer: Understanding encryption, public/private key, signatures and certificates

Kaushal - SSL Certificates

I am working on a project where I have multiple hosted WF services. All the services were secured using federated security with WIF and a custom STS. This has all worked fine until I added a new service workflow that needed to be accessible by anonymous users. This is where things get a little tricky.

The WCF configuration for the hosted services looked a little like this before the anonymous service was added.

The preparations for my CodeCampOz presentation have come a long way as has my understanding of the subject matter. I have tweaked my presentation abstract as a result. The new abstract is the following:

Not a WIF of federation

The Windows Identify Foundation (WIF) provides the latest Microsoft implementation for working in the claims-based identity space. WIF has particular strengths in providing federated security for systems that target users across multiple security domains, multiple credential types and multiple credential stores.

Developers of small systems may find it difficult to understand how WIF fits into their system design. Small systems tend to have their own security store, do not cross security domains and may not even run within an Active Directory managed domain. How do developers leverage claims-based security when they do not require federated security?

This session will provide a brief introduction to claims-based security and then look at how to implement WIF in ASP.Net and WCF applications without federation dependencies. It will then extend this to include a federation capable architecture.

This is a bit of a curly one. I have a workflow that is mostly abstracted from security concerns in that authentication and authorization logic has already been processed. The workflow does however need to get the name of the current user via Thread.CurrentPrincipal.Identity.Name. Unfortunately this returns an empty string when executing the workflow directly in a unit test.

The reason for the workflow not having access to the current principal is that workflows are executed on a new thread. The principal associated with the workflow thread is determined according to the PrincipalPolicy assigned to the AppDomain. By default the AppDomain will return an unauthenticated GenericPrincipal. See my Thread identity propagation post from a few years ago for the background information.