Ajden Towfeek

Towfeek Solutions AB

Lab days with focus on security (STS, WebApi, WCF and WIF)

Lab days once again at work, this time I focused on security. Can't share the code this time since it contains some company confidential stuff but the diagram below basically summarizes my architecture idea.

Securing WCF service with WIF

There are plenty of blogs out there descibing how to do this so I'm not going to explain this i depth, if you however only have experience with using WIF 3.5 as me I found an excellent migration guidelines page on msdn (http://msdn.microsoft.com/en-us/library/jj157089.aspx). We use a custom binding for tcp transport support with reliable sessions which makes you wanna kill yourself when you see the binding configuration. Due to this I can't share the code since it is considrered "intellectual property" of Saab (me?).

Important WIF 3.5 to 4.5 change!

You could previously access the calling users claims in the WCF service by casting ServiceSecurityContext.Current.PrimaryIdentity to ClaimsIdentity. This is no longer true, you'll get the claims by casting Thread.CurrentPrincipal to ClaimsPrincipal or Thread.CurrentPrincipal.Identity directly to ClaimsIdentity. For this to work you'll also need to set <serviceAuthorization principalPermissionMode="Always" /> on the service behavior declaration. See also Dominick Baiers post for more details.

JWT, Identity Server v2 and WebApi

I've updated our development STS in our product at work from startersts to identityserver v2, which I thought was a great platform to continue exploring, especially since it supported to issue JWT (json web tokens). At least I thought it did until I discovered that it doesn't! They do however have a branch that supports it and uses Microsoft JWT (https://github.com/thinktecture/Thinktecture.IdentityServer.v2/tree/Microsoft-JWT).

I found a nice message handler that validates JWTs which uses JSON Web Token Handler For the Microsoft .Net Framework 4.5 written by the security guru Vittorio Bertocci (http://code.msdn.microsoft.com/AAL-Native-Application-to-fd648dcf/sourcecode?fileId=62849&pathId=697488104). And as always I encountered major problems when trying to validate the JWT issued by identity server on the server-side (webapi). Victor uses windows azure ad together with Windows Azure Authentication Library which of course validates the token correctly.

I think there is a may release coming up for identity server, perhaps I'll give it another shot then, but for now I had to use Azure AD.

The outcome wasn't actually what I expected when I began but the road there was educative, I suggest following Victor on http://www.cloudidentity.com/blog to keep up with the updates on the json web token handler which currently only is in the developer preview stage. It hurts to keep up and always use bleeding edge technology but hey, they don't call it lab days for nothing. ;-)



What about WCF 4.5 and the async/await pattern?

From what I've heard it should be pretty smooth to produce asynchronous server/client code with .net 4.5, so let's try it out! Defining async methods on the service contract is now a lot cleaner :

public interface IPeopleService
	Task<IList<Person>> GetPeople();

instead of the wcf 4.0 way which would look something like this :

public interface IPeopleService
	IAsyncResult BeginGetPeople(AsyncCallback cb, object state);

	IList<Person> GetPeople();

	IList<Person> EndGetPeople(IAsyncResult ar);

the server side implementation of the operation when returning a task is straightforward :

public async Task<IList<Person>> GetPeople()
	Task t1 = Task.Delay(500);
	Task t2 = Task.Delay(500);
	await Task.WhenAll(t1, t2);

	return await Task.Factory.StartNew(() => people);

If you don't want to await something in the method you can skip the async keyword and still return a Task as shown below, async on a method simply tells the compiler that "I'm going to await something in this method".

public Task<IList<Person>> GetPeople()
	return Task.FromResult(people);

Anyways it's really nice to skip the non-implemented begin/end methods on the server which was simply boiler plating in .net 4.0. For the sake of simplicity the service will be hosted in a console application and for consuming the service I've implemented a simple proxy that inherits ClientBase<TChannel> and implements the contract. See the code if this confuses you (which probably means that you're a noob ;-)). The client code when working with tasks is clean and straightforward as well :

var serviceProxy = new PeopleServiceProxy("PeopleServiceEndpoint");

Task<IList<Person>> people = serviceProxy.GetPeople();
	x =>
			foreach (Person person in x.Result)
					"{0} {1} born {2}",

We can control on which thread we will continue by passing in a TaskScheduler. So far so good, so what about testing? I'm using Nunit which integrates really well with VS when using resharper. I want to write an integration test (not unit) to make sure everything works well including the WCF part since unit testing my simple service is too easy ;-) I'll host the service in the Setup method and take it down in the teardown. A simple test then looks like :

public void ShallBeAbleToGetDateTimeFromService()
	IPeopleService serviceProxy = new PeopleServiceProxy("PeopleServiceEndpoint");

	Task<IList<Person>> getPeopleTask = serviceProxy.GetPeople();

	IList<Person> result = getPeopleTask.Result;

	Assert.AreEqual(2, result.Count);

	(serviceProxy as IDisposable).Dispose();

Obviously we'd use facades to call on services in a real application but the principle is the same. It doesn't get much cleaner than this imo.


Get the code here! (67KB)