The Rise of Federation Part 1 - "Trust Me"

Do We Have Trust?

Back in 2005 a group of us in Microsoft Consulting Services (MCS) formed up in what was termed the COE - Center of Excellence and for my area that was OS/Identity. The focus and objective of the group was to engage in leading-edge infrastructure projects involving the operating system platform, Active Directory, and Identity Management. Along the way we hoped to identity and promote our collective best practices and also skill up some newer people in these disciplines. Anyway, one of the best weeks of training I ever took was in this timeframe when we learned about a new thing coming in Windows Server 2003 R2 called Active Directory Federation Services - ADFS.

In talking with the ADFS product team as led by Don Schmidt, their concern as to the ultimate success of ADFS was not whether the technology was credible. Indeed the technical underpinnings of ADFS are rock solid (more on that in a bit). But the fundamental issue at stake, where ADFS was really launching a new paradigm, was requiring a new kind of TRUST between business partners. While electronic interchange of business data amongst companies is nothing new, with EDI becoming commonplace in the 1960s, electronic interchange of security information was four years ago, and mostly still is, a topic that will send shivers down the back of most CSOs. So the catch phrase around ADFS phrased as a question was "Will People Trust?"?.

Federation Trust Today

So where are we now, after four years of experimentation, proofs of concept, pilots and some leading-edge implementations?. Well yes we do have some case studies - see for example here. Many customers have implemented some fairly extensive networks of trust. Some have used the WS-* protocols as implemented by Microsoft with ADFS, some have used other implementations of WS-* (IBM, CA, Sun, Oracle, Ping Identity, .), and some have used the SAML protocols. A large healthcare provider I spoke to had some 40+ business partners that were using federation to access web-based applications over the internet.

One of the hugest factors that contributed to this rise of trust is the overall maturing of the IT security industry and the practice of good security policy in enterprises. A couple years before my introduction to ADFS, I was at a conference on SQL Server in Seattle on the day that SQL Slammer was taking down most of the Internet. 2001 through 2003 were some dark years in the IT industry, with the dot com meltdown followed by a wave of very HECBURNAR (hectic, burly and gnarly!) large scale security issues. Since then Microsoft and our customers, along with the entire industry have learned so much across the spectrum of people, process and technology. All I will say on the technical front to wrap up that thought is that Defense in Depth is a very powerful approach.

So today we have federation technologies becoming more widely accepted, and in Windows Server 2008 we were able to make some minor improvements in ADFS. More info here. On the technical underpinnings of ADFS we have a very strong story to tell:

· Token signing is done via X.509 certificates.

· All communications amongst applications and federation servers must be done over SSL and secured by X.509 certificates.

· The WS-Federation protocol was from its beginnings a cross-industry movement aimed at standardizing the interchange of security information across infrastructures and applications. Indeed if you look at the WS-Fed spec it showed participation from not just Microsoft but also BEA, BMC, CA, IBM, Verisign, Novell and Layer 7.

· For ADFS the chief goal was in making identities stored in Active Directory to be transportable around and outside the enterprise.

· The ADFS policy store (in v1) is a single XML file. In ADFS "Geneva" we have a SQL Server policy store, much better.

Indeed with so much reliance on certificates that turns out to be one of the primary troubleshooting techniques that one must learn in setting up and using ADFS. The system administrator needs to have a thorough understanding of certificates and how they are managed.

The Rise of Federation - Windows Azure

While we have seen an increasing acceptance of federation technologies in large enterprises, the thing that convinces me most that federation and claims-based access models are here to stay is the reliance of the new Windows Azure platform on these concepts.

While reading the base Windows Azure whitepaper (a must read!) we come across the statement:

"And like the Service Bus, applications that interact with the Workflow Service must first get a token from the Access Control Service-it's the only trusted STS."

So in Windows Azure we have a very strong way of linking your enterprise Active Directory into the Azure cloud, we can also link other directory services using WS-Fed or SAML, and we have the notion of claims transformation as central. In order to build a real application with Windows Azure you're going to use the Service Bus and the Workflow Service, and in order to do that you're going to use a Security Token Service - which is the .Net Access Control Service. More information on the .Net Access Control service is here. The .Net Access Control Service is mainly there for authorization. (In the CTP version it can also provide authentication but that is a temporary measure). But for real authentication you will use Windows Live ID or use a federated identity linked from your enterprise into the Federation Gateway.

In order for cloud-based computing to become a real transformational force, one of the attributes it must have is a very strong security model. Microsoft is investing a very significant amount of resources to build that security model. For a great overview of how federation technologies really build the essential security bridge between enterprises and the cloud please see Kim Cameron's whitepaper Identity Software + Services Roadmap.

In graphical form one can see the tremendous power and flexibility of what is being built to allow strong identity and security within the Software + Services architecture of Azure. Kim's paper explains very clearly what each of these components are and what they do.

The Road Ahead

So for building federation infrastructures in the enterprise today we have ADFS V1 in Windows Server 2008, and we can link that to identity stores in AD and AD LDS. At the PDC in late 2008 we got the first beta of ADFS "Geneva", along with early versions of the entire S+S Identity infrastructure -the Federation Gateway, the Services Connector, the Geneva Identity Framework (this is how applications become identity-aware), and the new version of Cardspace.

In the months ahead we'll be getting Beta 2 of ADFS "Geneva" and updates of all the other major components. This is a great time to an identity and access architect and designer, and for the next couple of years people like me will be happily employed helping customers to plan for and realize the benefits of Federation and the claims-based identity model.

Subsequentia

In my next posting I have some further ideas to share on the rise of federation (Part Two coming up) and a chance to create some linkage to one of my favorite science fiction writers, Kim Stanley Robinson. But first I'm going to take vacation for a week.