The Freak Parade

Kill the User! Or, at least the Users table. As I explained in Part 1,  you’ll have a better chance of going to heaven if you do. In this post I’m going to offer my nearly-layman’s understanding of the Identity landscape as it seems to be  unfolding in the industry. The next post will be a link post, so if you tire of my rambling and ceaseless blah blah blah you can go read about some of this stuff from qualified experts.

So the question that is on everyone’s lips is this: if it no longer makes sense for each individual application to maintain its own catalog of users then what is the alternative? If you don’t maintain a list of users and what roles they have, how will you determine what they should or shouldn’t be able to do? If you don’t examine their usernames and passwords, how can you be sure they are who they say they are? Or, maybe it is time to abandon access control in computer systems entirely, issue in a new age of freedom and love, a sort of modern day hippie revolution? No?

Then welcome to the Identity Metasystem. The Identity Metasystem is an architectural arrangement that classifies Identity related activities into three distinct roles and specifies the interoperable protocols (all smelling strongly of SOAP and WS-*) available to each role when conducting Identity related business with each other. These three roles are:

1. Identity Provider (IP)
2. Relying Party (RP)
3. Subject

The basic idea is that if your system is participating in the Identity Metasystem, as all good, socially responsible systems strongly consider doing, you agree to relinquish control of authenticating your users and delegate that task to specialized systems, or Identity Providers (IP). Systems giving up their Users table that are now relying on an IP to authenticate their users are Relying Parties (RP). The users actually being authenticated by an IP in order to gain access to an RP are Subjects. To make all this a little more clear, I offer a parable:

A Subject walks into an RP and says ‘Give me a pint of your strongest data.’ The RP looks suspiciously at the Subject and says ‘wait just a minute buddy, I don’t have the foggiest idea who you are…’  The Subject pulls out his username and password and holds them out to the RP, who waves his hands in front of his face and shouts ‘Don’t show them to me! I don’t want to see your freaking password, show your credentials to the IP! So the Subject turns to the IP sitting at the next barstool and shows him his username and password. The IP examines the Subject’s credentials, sees they are valid, and initiates a complex series of hand signals that look a lot like gang signs. The RP compares the hand signals to a set of approved hand signals in a little book he keeps behind the bar and verifies that he trusts this particular IP. Satisfied, he serves the Subject his data.

To make this work the various roles in the Identity Metasystem  get on with each other by following the Laws of Identity as formulated by Kim Cameron, an architect at Microsoft and an Identity luminary. Additionally, all Identity funny business is transacted using interoperable, WS-* based protocols like WS-Trust and WS-Federation, allowing complete freedom in platform and technology choices when building or migrating systems to participate in this New World Order.

Claims Based Authorization

Many, if not most, existing systems rely on Role Based Authorization to authorize user activity. Role Based Authorization is often very specific to an individual system - the system stores what roles a user has, and looks up those roles when a user logs in to make decisions about what that user can do. This is all good and well, but it isn’t exactly practical in a system that has outsourced its authentication to an IP (even if the IP is controlled by the same organization as the system in question) because individual software systems don’t own their users in the Identity Metasystem - the IP’s maintain user records on behalf of users of multiple systems.

The solution is for the IP’s to maintain what roles a user has, and those roles will travel from system to system along with the user. And instead of just having a flat list of roles, users travel around with all kinds of useful information that might be useful to RP’s wanting to make authorization decisions, like a users age or how long an employee has been with the company. These bits of information are known as Claims. A Claim is really nothing but a name value pair, but like ID cards in a person’s wallet, all of this identifying information is always with the user. At any time a Relying Party can examine the authenticated user’s set of claims to make an authorization decision. In the end this way of working is infinitely more  flexible and sociable than the old way.

From a technology perspective, claims are represented and transmitted as encrypted, signed interoperable tokens (usually SAML - Security Access Markup Language) that are issued upon request by the Security Token Service (STS) of an IP and presented to a Subject to give to an RP. Alternatively tokens may be provided directly to the RP once the user has been authenticated.

I think that is more than enough for now. Next post I will talk about specific technologies in the Microsoft world that can make building this kind of functionality into your own applications pleasantly easy, as well as give a very brief overview of Identity Selectors, such as Windows Card Space, and where that technology fits into this picture. And of course the usual collection of links. Next: Part 3 and Part 4.

Another free e-book is available to the knowledge thirsty among you. This time it is Data Structures & Algorithms, a topic which nicely compliments some of the other free e-books that have become available recently. With free learning materials like this around, why waste your money on college? If you’re currently in college, drop out now. If you’ve already graduated, demand a refund! Instead, read Data Structures and Algorithms to get your foundations in computer science, then Foundations of Programming to become familiar with how modern, forward thinking .NET systems are built, and follow it up with Domain Driven Design Quickly to top off your education in cutting edge object oriented design. You can add some spit-shine to your newly enlightened brain with Service Oriented Architecture - Getting It Right and a free subscription to The Architecture Journal. BAM! You’re a high priced, SOA savvy Enterprise Architect with a swagger in your step and farts that smell like french perfume.  And you haven’t dropped a dime on college.

I have uploaded a new project, Simple Expression Evaluator, to Codeplex. I haven’t had time to create any documentation yet, but as usual the project contains unit tests and a sample application to play with. Simple Expression Evaluator abstracts the the parser+compiler from the object model, allowing any kind of parser to be used to construct expressions. Simple Expression Evaluator works by converting an Abstract Syntax Tree into an Expression Tree and evaluating the expression tree. A discussion of dynamic expression evaluation and links to resources can be found here. It is very simple to add new language elements, operators or functions, and comes with an array of options for plugging in custom variable evaluators or function evaluators by either implementing an interface or by associating events with delegates. 

Simple Expression Evaluator’s default parser and expression language use the Irony.net Compiler toolkit. The expression language itself is a modified, stripped down version of Script.NET (S#) and supports things like array indexers and aggregate functions such as Sum, Avg, etc that can be used on collections. Here is a screen shot of the sample app:

Ernst Naezer has generously contributed some very welcome enhancements to the Simple State Machine that adds new extensibility points and support for database workflow persistence, allowing the default file system workflow persistence mechanism to be replaced. Ernst has also provided a nice, concise tutorial on using this new feature with Castle ActiveRecord. The tutorial even contains a fully functional sample application demonstrating the persistence technique. I will probably add the sample to the main project at some point, but for now the sample can be downloaded from a link on wiki page.

Thanks to Ernst for all his hard work on this library.