Geneva Distilled

I don't know about you but I'm not what you would call a "security guy". Sure, I know how to write secure code and I've done my share of encryption programming and SSL and forms authentication and windows authentication in applications, but that doesn't make me a security guy. 

Think of it this way. I've got a toolbox with a bunch of tools in it. I know how to use the screwdriver and I know how to use the hammer. The security guy, however, can look at that toolbox and build a backyard BBQ complete with big-screen TV. I, on the other hand, would probably end up building a shaky birdhouse that makes all the nearby birds go, "WTF?!".

The point here is that when I talk to security people about Geneva, they usually only need one or two sentences of overview and they get it. Developers who have been working with applications secured using conventional/traditional means often don't have enough context to dive right into the Geneva documentation without feeling lost.

So I'm going to try and explain Geneva in terms that developers who have spent most of their time using various flavors of "credential passing" can easily digest. I think the most important thing to keep in mind while reading this is a conversation I had with a true security guy once. I said, "What's the safest way to send credentials so they can't be spoofed, re-directed, or stolen?" He responded with, "Don't send 'em".

A Brief History of Geneva

Disclaimer: This is the history as far as my involvement goes back. There could easily be many more months or years of history that I'm not aware of. I remember back as far as PDC 2003 (seriously, I can actually remember that far...). They handed out these nifty little flashlights that said "WinFX" on them (I still have it!). WinFX was then the codename for what would encompass the codenames for Avalon (WPF), Indigo (WCF), Workflow Foundation, and this other obscure and confusing thing called InfoCard.

What InfoCard set out to do was to allow the desktop GUI to present the user with a list of "Cards". These cards could then be sent to a website (that had suitable WCF + InfoCard coding on it) and the website would know who they were. The grand scheme was to eventually see things like your own VISA card in this list, issued to you by your credit card company. Whenever a website asked for a credit card, you could "show" them this card and the site would be able to make your purchase without ever having been given direct access to your credit card number.

There are a few hundred tangents I could go off onto here but the main thing that I felt was that InfoCard was ahead of its time. There were trust issues, issues with it requiring Longhorn (during the first preview we got to see anyway) and even more of a barrier was that every site would have to do extensive work just to support this thing that currently had 0 adoption rate.

Over the years InfoCard became CardSpace and it got better at doing what it did, but the adoption rate (at least within my circles) was limited to 0 commercial users and the rest were developers doing samples for blogs and conferences.

Then came a project called "Zermatt". Zermatt, in my opinion, was an attempt to decouple all of the various pieces that made up the CardSpace infrastructure and finally make the use of tokens (discussed below) more standardized, more open, and more importantly, easy for developers to adopt. I played with Zermatt, loved it, thought it was a great improvement over previous incarnations of CardSpace... but it still felt lacking. Sure, it was a nicer, friendlier, more accessible CardSpace but it didn't make the adoption of federated identity and claims-based authorization (again, discussed below) easier in an enterprise.

This is where Geneva comes in. Geneva is a suite of products consisting of: Geneva Server, Geneva Framework (.NET SDK that does not require a PhD in security to consume), and CardSpace "Geneva". The Geneva Server looks to be something that you can simply install, configure easily, and fire it up and you now have Geneva support in your enterprise. Let's hope it continues to aim for that target. Geneva is currently in Beta 1 and you can download it from Microsoft.

Claims vs. Credentials

If there was one thing that I thought you needed to be able to firmly grasp about Geneva it would be the concept of claims. Claims are something that may feel very new and very alien to developers used to the traditional model that looks something like this:

User hits your website (or your desktop app..) and is prompted for a username and password. The user then submits their credentials. Your website grabs those credentials and validates the user. If the user is valid, the website can then go fetch the user's profile information and other information about the user including the roles to which they belong for security purposes.

What Geneva (and other industry standard solutions that conform to the same set of protocols and languages that Geneva speaks (more on that later)) operates on are claims. A claim is really just a statement of fact. It could be anything from "my name is Kevin" to "my credit card number is 1111-1111-1111-1111". Claims are very special statements of fact, however. Every claim comes with a sort of guarantor - some entity that has certified that claim to be true. You, as a developer, also get some information about the entity certifying the claims.

Here are some more examples of claims (deliberately not showing what a claim looks like in code):

• My name: Kevin, Issuer: Me
• My e-mail address: alothien@gmail.com, Issuer: Gmail
• My security role: Administrator, Issuer: FantasticSite.com

As the developer of a site that accepts claims I realize that the "name" claim is self-certified which means it's pretty insecure (the user can pick anything they like). But, in a lot of cases, especially for sites like a message forum, I really don't care if the user is who they say they are. The e-mail address claim is interesting because (assuming Gmail was involved in this scenario) we can verify with 100% certainty that the e-mail address for that user did actually come from Gmail. Finally, we see that the user is also claiming to have administrative access on the site FantasticSite.com. If we have a trust relationship (federation anyone?) with FantasticSite.com, we can then know without a doubt that the user is actually an administrator.

Couple of things of note here... First - there are no credentials. There is no username and no password in this set of claims. Now, the user may have had to enter a username and a password in order to be given one of the claims (like the Gmail address), but that username and password was only ever sent to Google, not us. Second - we know who certified the claim and we also know how much we trust claims from that source and we can use that to make an informed decision about whether or not we're going to accept the claim. [Oversimplification Warning] basically the entity that certifies the claims digitally signs the claim with it's private key. We then use the public key to verify the signature. In this fashion, we know without a doubt that the claim came from that entity and hasn't been tampered with or faked.

Security Benefits

So now we have a basic idea that Geneva works by taking the authentication and authorization bits that are normally hand-rolled by your team and tightly coupled with your solution and abstracting it out to the use of external parties. So what exactly does this buy you from a security standpoint?

As I mentioned earlier, what this means is that no two relying parties (sites/applications that rely on a Geneva or Geneva-like infrastructure) need to share the same backing store for users. This means that secure user information is never stored outside the single authoritative location for that user information. More importantly, the user (or client application) will never need to submit credentials over the wire to parties who don't own those credentials. Think about the number of times you've seen in the news about hackers cracking into some website and stealing credit card numbers from purchase histories. What if the site never needed to know your credit card number? What if you could still securely and easily use that site, but that site was never given any information that could harm you if stolen.Obviously the site would have to be playing ball with the whole WS-Trust, WS-Policy, and WS-Security stuff but you get the idea.

To really simplify things down: Using Geneva, you can walk up to any website or web service built by any team or department within your organization and say "hey, I'm Bob and I'm going to be consuming your services tonight." and then the site/service can reliably, with certainty, be able to say "OK Bob we believe you. Enjoy your stay." This leads me to the organizational and Single-Sign-On (SSO hereafter) benefits.

Organizational & SSO Benefits

For me, as an architect and developer, this is where Geneva starts to get really appealing. Picture this scenario: In your organization you've got 5 different departments. Between those 5 departments they are creating 7 different applications. All of these applications have strict mid-tier requirements and so all of them have these back-end infrastructure services exposed that all other applications can consume to share data. It's an awesome architecture that involves cats and dogs living together in total harmony... except for authentication and authorization. This beautiful architecture typically degrades into multiple silos of user authentication. Each department has their own unique customer base. They have different information they need stored about different users. Worse, many of these applications use different types of credentials to log in.

So now let's say you're a developer on Team A and you want to use a service written by Team B that lets a customer of Team A's application create a new order in Team B's application. Great! Cross-sell opportunities FTW!!1 Here's the rub: Team B's application has no idea who the hell any of Team A's users are. Now things get really messy and people start creating these "bridge users" in each of their user silos to allow Team A apps to log in to Team B services. So now when Team A wants to create an order in Team B's app, Team A consumes the Team B services by logging in as "teama" with a password of "teama". If you've never been in this situation before...trust me, it smells bad and it's a downhill spiral that is really hard to escape.

This is where Geneva comes in. Let's refactor the previous scenario using Geneva. First we've got a Geneva server in the enterprise. There are trust relationships set up between the different teams and each team has a service that can certify claims made as to the user's identity and their security privileges.

Now a user of Team A wants to do something that will create an order in Team B's application. The Team A application walks up to the Team B service and says, "Hey my name is Bob. you don't know me, but (TeamA) says my name is Bob and that I'm allowed to use your service." The TeamB application responds with, "Sweet. Me and TeamA go WAY back. Oh, hey, your claims also have your billing address and other information that I couldn't possibly have known otherwise. Thanks."

So what just happened? Two applications with two completely different architectures that both rely on back-end web services that both have two completely isolated user databases were able to communicate securely. Without either app being aware of the other application's user information and without creating hacked "bridge users", one app was able to talk to the other app securely.

So if you have ever seen the situation where you've got multiple web services that need to talk to each other securely (regardless of whether or not there is a shared user base), then Geneva could come in really handy. Now when you add in the ability to federate with other organizations outside your building without needing to maintain remote user information locally... now you're starting to talk about real value-add and real savings in terms of cost, time, effort, and aspirin consumed.

I plan on keeping my eye on Geneva as it matures but so far what I've seen is pretty impressive. I'm still doubtful about whether users will ever "get" the whole card space stuff but that's OK since you don't actually have to use card space for the scenarios I discussed above. From what I've seen, if the users know what it actually is, they're on board. But more often than not, it's so strange and unfamiliar to them that they're not sure what's going on... and if an end user is confused, they will NOT click the "next" button. They will hit "cancel" and never use your site again.

tags: geneva  microsoft  zermatt  cardspace  identity  

links: digg this    del.icio.us    technorati    reddit