Project Geneva – Part 2

[This is the second installment of a presentation I gave to Microsoft developers at the Professional Developers Conference (PDC 2008) in Los Angeles. It starts here.]

I don’t want to overwhelm you with a shopping list of all the scenarios in which the Claims-based architecture solves problems that used to be insurmountable.

But I’ll start from the enterprise point of view, and look at how this system helps with the big new trend of federation between partners. Then we’ll look at cloud computing, and see that the same architecture dramatically simplifies developing applications that can take advantage of it.  Finally, we’ll see how the approach applies to consumer-oriented web applications.  

Enterprise Federation

The rigid Enterprise perimeter is dissolving as a result of the need for digital relationships between an enterprise and its suppliers and customers, as well as the outsourcing of functions and services, the use of temporary workers, and having employees who sometimes work from home.  The firewall is still a useful element in a concentric set of defences, but must at the same time now be permeable. 

Most of us are even learning to collaborate on a per-project basis with partners who in other contexts might be our competitors.  So the relationships between business entities must be defined with more and more granularity.

In looking at this, I’m going to start with a very simple scenario – a story of two companies, where one has built an app in-house or has installed an ISV app for their own employees, and now wants to extend access to employees from a partner.

In the past, even this simple requirement has been really hard and expensive to fulfill. How can Microsoft help you solve this problem using the claims model?

Code name Geneva

Well, I'm happy to announce today, the first beta of “Geneva” software for building the claims-aware applications I’ve been talking about. It has three parts:

1. The “Geneva” Framework: A framework you use in your .Net application for handling claims. This was formerly called “Zermatt”.
2. “Geneva” Server: A claims provider and transformer (STS) integrated with Active Directory.  It comes with Windows, and makes managing trusts and policies easy.  Importantly, it supports Information Cards, making it easier for people to understand what identities they are using where, and to avoid phishing of their enterprise credentials. You may in the past heard this server being referred to as AD FS “2”.
3. Windows CardSpace “Geneva”:  The second generation Information Card client for federation that is dramatically faster and smaller than the first version of CardSpace, and incorporates the feedback and ideas that have emerged from our customers and collaborators.

In the use case we’ve been considering, our solution works this way:  each enterprise puts up a single Geneva Server – leveraging the power of their Active Directory.

Then the administrators of the application alter the .NET configuration to point to their enterprise’s Geneva server (with the config change I demonstrated here ). At this point, your customer's application has become part of what we call an Enterprise identity backbone, and can accept claims.

So the software framework and components provide a single identity model that users configure in any way they want.  If you have written to this model, your app now works for both “employees” and “partner users” without a code change. All that is required is to set up the Geneve STS’s .

The fatal flaw

Anyone who has been around the block a few times knows there is one fatal flaw in the solution I’ve just described.

Your customer may have partners who don’t use Active Directory or don’t use Geneva or have settled on a non-Microsoft product.

No problem.  All aspects of Project Geneva are based on standards accepted across the industry – WS-Trust and WS-Federation.

I’m also very happy to announce that Geneva supports the SAML 2.0 protocol. Basically, no system that supports federation should be out of reach.

All this means your partners aren’t forced to use “Geneva” if they want to get access to your applications. They can use any third party STS, and that is part of the great power of the solution.

Does Microsoft practice what it preaches?

Microsoft is an enterprise too.  So if this architecture is supposed to be good for our enterprise customers, what about for Microsoft itself?  Are we following our own advice?

I’m here today to tell you Microsoft has fully stepped up to the plate around federation. And it is already providing a lot of benefits and solving problems.

You've heard a lot at the PDC about Azure. Microsoft offers cloud applications like hosted SharePoint and Exchange, and cloud developer services like the .Net Services and SQL Data Services, as well as a whole range of applications.  We want other enterprises to be able to access these services and sites, much like other enterprises want their own customers and partners to access the systems pertaining to their businesses.

So we make our offerings available to customers via the Microsoft Federation Gateway (MFG), which anchors our “services identity backbone”, and is based on the same industry standards and architecture delievered through the Geneva Project's server. It is all part of one wave, the Geneva wave of Identity Software + Services.

The result is pretty stunning, in terms of simplifying our own lives and allowing us to move forward very quickly – as it will be for enterprises that follow the same route. Through a single trust relationship to our gateway, our customers can get access to our full range of services.

Again, we’re not telling our customers what federation software to use. They can federate with the MFG using “Geneva” or other third party servers that support standard protocols.  And they can use the same protocols to federate with other gateways run by other organizations.

What about Live ID?

It is important to understand that the Microsoft Federation Gateway is different from Windows Live ID.  Yet Live ID feeds into the Gateway just as all our partners do.  I'll describe this, and the cool implications for application develoeprs of this approach, in the next installment.