Rabbit in the headlights (Windows Identity Foundation woes)

I’m working on a new project at work, and part of my role as architect is to decide how we’re going to build authentication and authorisation. This will be a desktop smart client application deployed via ClickOnce that will use web services (hosted by us at our datacentre) to operate, with a dash of local caching for offline operation where applicable. We already have an ASP.NET website that has auth/authz behind it, so ideally I’d like to build on that.

After much internetting, I re-discovered Windows Identity Foundation (WIF), having heard a little about it on a DotNetRocks episode some time back. I like the concepts – separating auth/authz from your applications and instead obtaining tokens containing the claims the user has.

Sounds great. In theory.

In practice, it’s appears WIF suffers from “Over-engineering Microsoft Giddyness” syndrome. I’ve watched various WCF Pluralsight videos (which are excellent, by the way) to try and get a basis of understanding for WIF, but when I really got into WIF itself, it’s too much for my small brain to cope with.

Essentially I’ve worked out that I want to have an “Identity Provider” that my desktop app can authenticate with, and that will return a security token in exchange for a valid username and password. I then want to be able to pop that token into subsequent calls to the other WCF services, which will then investigate the claims supplied in that token to establish whether the user can carry out those operations or not. However it seems writing my own Identity Provider that works off our user store is, ahem, “non-trivial”. There are a few choices of existing ones out there in the world., but it all seems like over-kill to me.

So I’m going to steal the idea and Build My Own. I’ll have a WCF service that is accessed via SSL that will return a token containing various information (“claims” in WIF parlance) about the user in exchange for a valid username and password. This token will then be made available in the SOAP headers of calls to our other web services (also accessed via SSL, so it’s okay Smile).

I know what some of my readers will be thinking – that there’s a reason for the engineering that’s gone into WIF. The truth is that this approach should work just as well. I’ll need to have a think about possibly signing the token and encrypting it so that the web services can be confident the data hasn’t been tampered with or otherwise intercepted, but I’m willing to be my small brain comes up with The Simplest Thing That Could Possibly Work. A key tenant of Domain Driven Design, and something else I’m going to strive for on this project.

Advertisements

5 thoughts on “Rabbit in the headlights (Windows Identity Foundation woes)

  1. Hi Neil,
    I’d be interested in understanding what led you to think that writing your own IP from scratch would be easier than using the WIF classes and model for that. We normally suggest caution when you write your own STS because it is such a vital part of one architecture and building secure/available/manageable/scalable services is a hard exercise per se, which is why you are normally better off by using a product whihc does that. BUT: if you decide that you want to build something froms cratch anyway, it is WAY easier to use the classes and the model already baked in: you won;t have to worry about signatures, encryption, data model for the claims, putting them in and out of the current principal, and so on.
    Also, the material you’ve been using could be updated (I saw it stillr efers to “geneva”, thatw as 2 years ago). I would recommend you take a look at the labs in the identity training kit, they contain many labs which use simple custom identity providers that can give you a starting point: http://www.microsoft.com/downloads/en/details.aspx?FamilyID=c3e315fa-94e2-4028-99cb-904369f177c0

    Good luck!
    V.

    • Oh I don’t think writing a WIF-scale IP would be easier, I’m saying that I need a component that does a similar job but without the “enterprisey” nature of WIF. My problem in fact is that I’m working on a project largely by myself that needs clients to authenticate with a server, and I need to use our existing auth/authz data (as used by our existing systems). I don’t want to buy in a large-scale enterprisey IP, so I need to “build my own”. I’m going to take your advice to work through those labs and see about creating a custom IP using WIF classes at least, and see where to go from there.

      Essentially my concern was that I don’t have enough time or a large enough brain to fully grok WIF, but I’ll give it another go. 🙂

      • I suggest looking at the lab \Labs\MembershipAndFederation, which shows how you can take an existing web site with an authentication system already in place and transform it into one IP. There we start from the ASP.NET membership, but the approach will work with any redirect based authentication scheme

  2. I’m in the midst of researching WIF, ADFS2, & AD LDS to replace existing authentication at our enterprise. We have user accounts in two separate legacy silos in addition to Active Directory. What I’d like to do is use these frameworks and create our own STS (by extending SecurityTokenService — http://tinyurl.com/63npsav) to authenticate accounts against AD LDS.

    Is this different from the approach you’re trying?

  3. Hmm it seems like your site ate my first comment (it was super long) so I guess I’ll just sum it up what I had written and say, I’m
    thoroughly enjoying your blog. I as well am an aspiring blog
    blogger but I’m still new to everything. Do you have any helpful hints for rookie blog writers? I’d certainly appreciate it.

Comments are closed.