New test results for SAML Profile For eGovernment

The success of the Identity Metasystem depends heavily on having products available from multiple vendors that are proven to interoperate and ready to deploy.  Kantara Initiative and Liberty Alliance have contributed significantly to this by helping test products against specific profiles.  Kudos to everyone involved with the definition, organization and testing of the eGovernment SAML 2.0 profile v1.5.  This represents a real step forward given the diversity of products involved.

SAN FRANCISCO, Sept. 30  — Kantara Initiative and Liberty Alliance today announced that identity products from Entrust, IBM, Microsoft, Novell, Ping Identity, SAP and Siemens have passed Liberty Interoperable(TM) SAML 2.0 interoperability testing. These vendors participated in the third Liberty Interoperable full-matrix testing event to be administered by the Drummond Group Inc., and the first event to test products against the new eGovernment SAML 2.0 profile v1.5 recently released by Liberty Alliance. Web-based full-matrix testing allows vendors to participate from anywhere in the world and features rigorous processes for ensuring products meet SAML 2.0 interoperability requirements for open, secure and privacy-respecting federated identity management.

“The summer 2009 full-matrix testing event included more vendors than ever before, reflecting the worldwide demand among enterprises and governments for SAML 2.0 identity-enabled solutions that have proven to interoperate,” said Roger Sullivan, president of the Kantara Initiative Board of Trustees, president of Liberty Alliance and vice president, Oracle Identity Management. “Organizations can count on Liberty Interoperable for products that have proven to meet interoperability requirements today and over the long-term as the program moves to expand within Kantara Initiative to test against additional identity standards and protocols.”

This year's program featured enhanced SAML 2.0 testing scenarios between Service Provider (SP) and Identity Provider (IdP). The eGovernment SAML 2.0 profile and its requisite test plan have been developed by Liberty Alliance with input from the Danish, New Zealand and US governments. Testing processes for the eGovernment profile included multiple SP logout scenarios, requested authentication context comparisons, and other aspects of SAML 2.0 necessary to meet interoperability, privacy, security and transparency requirements in the global eGovernment sector. A review of the SAML 2.0 v1.5 eGovernment profile is available here.

“SAML 2.0 is the most popular federation protocol in the industry and utilized by commercial, educational, and government institutions around the globe,” said Gerry Gebel, VP and service director at Burton Group. “Federated single sign-on demand is growing, spurred by broad adoption of SaaS applications and the general increase in collaboration among business partners in every industry. The Liberty Interoperable program is instrumental to sustaining successful deployments in advanced federation scenarios where multiple products are in use.”

During the July 14 – September 4, 2009 testing event, the following products demonstrated interoperability based on a variety of SAML 2.0 conformance modes. A detailed list outlining what each vendor passed is available at http://tinyurl.com/yahs2u8

Entrust — Entrust IdentityGuard Federation Module 9.2 is a part of Entrust's versatile authentication platform, supporting numerous authentication methods in one cost-effective solution. Organizations are empowered to choose the right authentication method(s) for their users accessing enterprise, consumer, government or mobile applications. Entrust IdentityGuard includes support for username & password, IP-geolocation, device-ID, questions and answers, out-of-band OTP soft tokens (via voice, SMS, e-mail), grid and eGrid cards, digital certificates and a range of hardware OTP tokens. Entrust IdentityGuard enables rapid deployment, centralized policy management, and an easy integration into the enterprise. Entrust IdentityGuard also includes the ability to apply transaction digital signatures for increased confidence in online transactions. Entrust IdentityGuard serves as a certified SAML 2.0 identity provider, providing standards-based interoperability to organizations. Combined with Entrust's zero-touch fraud detection solution, Entrust IdentityGuard provides a powerful risk-based solution for authenticating users.

Entrust — Entrust GetAccess 8.0 delivers a single entry and access point for user authentication and authorization across multiple Web portal applications. The solution delivers full service provider (SP) capabilities and provides organizations with security, flexibility and performance to personalize the user experience of a Web portal through the following key services: flexible authentication, including seamless integration with Entrust IdentityGuard for step-up authentication; proven authentication interoperability via standards such as SAML, Kerberos, X.509 and others; SSO to Web and non-Web applications via SAML; authorization including fine-grained access control to online resources; rich policy management capabilities, allowing controlled access based on environmental considerations (e.g. authentication method used, physical location, TOD, external data sources); centralized session management; personalization of content; integration with leading application and portal vendors; web-based tools for business administration and operational control.

IBM — IBM Tivoli® Federated Identity Manager (TFIM) 6.2 provides a full featured web access management solution for managing identity and access to resources that span companies or security domains. Rather than replicate identity and security administration across companies, Tivoli Federated Identity Manager provides a simple, loosely coupled model for managing trusted identities and providing them with access to information and services including SaaS and cloud-based deployments. For companies deploying Service Oriented Architecture (SOA) and Web Services, TFIM provides a centralized identity mediation services for federated Web services identity management across multiple domains (e.g. Java, .NET and mainframe). TFIM supports the following standards: SAML Protocol 1.0/1.1/2.0, OpenID Authentication 1.1/2.0 – OpenID Simple Registration Extension 1.0, Information Card Profile, WS-Federation Passive Requestor Profile, Liberty ID-FF 1.1/1.2, WS-Trust 1.2/1.3.

Microsoft — Microsoft Active Directory Federation Services (AD FS) 2.0 enables Active Directory to be an identity provider in the claims based access platform. AD FS provides end users with a single sign-on experience across applications, platforms and organizations and simplifies identity management for IT Pros. AD FS 2.0 is part of the Windows Server platform, and supports both on-premises and cloud solutions.

Novell — Novell Access Manager 3.1 simplifies and safeguards online asset-sharing, helping customers control access to Web-based and traditional business applications. Trusted users gain secure authentication and access to portals, Web-based content and enterprise applications, while IT administrators gain centralized policy-based management of authentication and access privileges. What's more, Novell Access Manager supports a broad range of platforms and directory services, and it's flexible enough to work in even the most complex multi-vendor computing environments. Novell Access Manager makes administration easy. You can use it to centralize access control for all digital resources, and it eliminates the need for multiple software tools at various locations. One access solution fits all applications and information assets. In addition, Novell Access Manager includes support for major federation standards including Security Assertions Markup Language (SAML), WS-Federation and Liberty Alliance.

Ping Identity — PingFederate v6.1 is an Internet Identity Security platform that delivers an enterprise-class, scalable, cost effective and standards-based software solution for enabling Internet Single Sign-On, Identity-Enabled Web Services and Internet User Account Management. PingFederate provides a centralized platform for managing all of your external identity connections with customers, Software-as-a-Service (SaaS) and Business Process Outsourcing (BPO) providers, partners, affiliates and others. Your organization can have Internet SSO and Identity-Enabled Web Services connections in days with point and click connection configuration, out-of-the-box integration capabilities, multi-protocol support, and automated user account management. Over 350 enterprises and service providers worldwide base their Internet identity security strategy on PingFederate.

SAP — The next release of SAP NetWeaver Identity Management 7.2 is planned for the second quarter 2010. SAP plans to significantly enhance the product with an Identity Provider (IdP) and Secure Token Service (STS) to support web-based Single Sign-On via SAML 2.0 assertions, identity federation and Single Sign-On for web services. The existing features to centrally administrate and provision users — provided by the Identity Center and Virtual Directory Server components — will be extended and allow for integrated scenarios with the IdP. The new IdP and STS will add access management features to the SAP NetWeaver Identity Management and allow the solution to be integrated into an Enterprise Single Sign-On environment reducing TCO and administrative effort.

Siemens — DirX Access V8.1 is a comprehensive solution that integrates access management, entitlement management, identity federation, Web services security, and Web Single Sign-on in one single product to protect your web applications and web services from unauthorized use. DirX Access provides for the consistent enforcement of business security policies through external, centralized, policy-based authentication and authorization services, enhances Web user experience through local and federated single sign-on and supports regulatory compliance with audit and reporting both within and across security domains.

About the Liberty Interoperable Program

The ongoing success of the Liberty Interoperable program is demonstrated by the wide scale deployment of SAML 2.0 products and the increasing number of businesses and governments such as the US GSA, now requiring vendors to pass Liberty Alliance testing. With nearly seven years of testing products for true interoperability of identity specifications, Liberty Alliance expects to expand the Liberty Interoperable program within Kantara Initiative to reflect growing momentum for proven interoperable multi-protocol identity solutions. More information about the program, including a list of all vendors who have passed Liberty Alliance testing, is available here.

Enterprises and governments are going to be able to do important projects and derive tangible benefits very quickly using this cross-vendor family of products.   That's really important.  Of course, there's more to identity than browser-based federation…  But one of the most encouraging signs is that the same kind of progress we see in the Kantara announcement is being made with the user-centric and privacy-enhancing technologies that many of us are working on to complement the SAML technology.

 

Real business on Geneva

Network World writer John Fontana has turned his tweet volume up to MAX this week covering TechEd.  I think it works – I'm enjoying it – though the sheer volume of Fontana Tweet makes it pretty hard to get your usual bird's-eye view of who is eating donuts, listening to new bands and staying up till all hours (can I live without that?).   John also posted a news piece announcing that Microsoft IT has turned on Geneva for widespread production use internally.

Funny, last week I was at the Kuppinger Cole European ID Conference in Munich (more soon).  Dave Kearns (one of John's colleagues at Network World) hosted a panel where he asked Vittorio and me whether Microsoft was actually using the Geneva technology.  

I waved my arms pathetically and explained that our IT department had strict procedures establishing the point in the ship cycle where they will do production deployments.  Well, now Beta 2 is out the door and it's great that our IT has sufficient confidence to move immediately towards widespread internal usage.   

‘LOS ANGELES – Two days after shipping the second beta of its newest identity platform, Microsoft's internal IT department is rolling out the software corporate wide.

‘Geneva, Microsoft's identity platform for the cloud, will support 59 identity applications that Microsoft maintains with 29 business partners.

‘The federated applications include a payroll services and an online company store.

‘The company's IT department will change DNS records today on its internal network so all its identity federations are handled through its Geneva server environment rather than the current five Active Directory Federation Servers (ADFS) the company runs, according to Brian Puhl, a technology architect for Microsoft IT.

‘Microsoft has nearly 410,000 computers and 165,000 users on its network.

‘Puhl laid out the plan Tuesday during a session at Microsoft's annual TechEd conference. He said the cut over initially moves the company from ADFS 1.0 to ADFS 2.0 in Geneva, but that over time Microsoft will take advantage of streamlined support for its Live ID technology, incorporate CardSpace-based identity and roll-out claims-aware applications that are in development at Microsoft. (See graphic of Microsoft's Geneva architecture.)

‘”Geneva is a lot more than ADFS 2.0,” Puhl said.

‘Geneva was released in public beta for the first time Monday and Microsoft plans to make the software generally available at the end of 2009.

‘The identity platform's foundation is the claims-based access model and Security Token Service (STS) technology that Microsoft has been developing over the past few years as part of its industry effort to create a single identity system based on standard protocols.

‘Geneva is made up of the Geneva Server, formerly called Active Directory Federation Services 2.0; Geneva CardSpace Client, a smaller and faster version of the identity client now available with Vista; and the Geneva Framework, which was formerly code-named Zermatt.

‘Also part of the platform is the Microsoft Service Connector, the Microsoft Federation Gateway and the .Net Access Control Service, which are designed to create a sort of identity backbone and connection to the cloud.

‘Microsoft plans to tap that backbone to link to cloud services, including its Business Productivity Online Suite (BPOS). ‘

More here.

Identity Software + Services Roadmap


I continue to receive many questions about how enterprise and government environments and systems can interact with new generations of services that are being hosted in the cloud, especially from an identity management point of view.

It is a fascinating question and getting it right is key.  I think about it a lot these days – as I'm sure everyone in the industry does.

One conclusion:  these new questions are the side-effects of trends we've been witnessing for a long time now – in particular, the decline and fall of the “closed domain”. 

Metadirectory, in the last half of the 1990’s, was the first step towards understanding that even with standards and widespread technological agreement, there would be no single “center” to the world of information.  There were multiple boundaries required by business and government, but by their very nature those boundaries always had to be crossed…  This was a profound contradiction but also a motor for innovation.  We needed kinder, gentler systems predicated on the idea they would have to interact with other systems run by independent people and organizations.

The concept of identity federation arose to facilitate this.  Over time agreement grew that federation was actually something you were able to do once you re-thought the world from a multi-centered point of view – one which allowed multiple viewpoints and criteria for action (call it truth).  This became generalized into “claims-based” system design – an approach in which assertions always have a source and must be evaluated prior to acting on them (i.e. we can accept assertions from multipe sources because our systems include mechanisms for deciding what they mean).

The notion of consuming and combining services, some of which we host ourselves, and others which are hosted for us by third parties, fits perfectly into this multi-centered view.  And in a world of claims-based system design, the combination of cloud and enterprise computing is a completely natural “atomic” capabiity.  So all the work the industry has been doing to advance claims-based computing lays the foundation for these new computing paradigms and makes them dramatically more practicable.

My presentation to the Microsoft Professional Developers Conference was a concrete look at how claims-based system design affects developers, and the synergies they will obtain by adopting the model.  It argued, in essence, that there is ONE relevant architecture for identity (NOT to be confused with “one single monolithic identity, which is an anathema!)  That ONE architecture works in the enterprise, in the cloud and in the home, and works on many loosely-coupled systems designed by many vendors to do many things – in the enterprise and in the cloud.

The presentation also discusses a number of the components we are beginning to make available as software products and services across Microsoft.  It underlines that these components implement widely adopted standards and their very goal is interoperable systems that are synergetic for customers.

The PDF is here, and the Word 2007 version is here.

 

Project Geneva – Part 5

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

I've made a number of announcements today that I think will have broad industry-wide support not only because they are cool, but because they indelibly mark Microsoft's practical and profound committment to an interoperable identity metasystem that reaches across devices, platforms, vendors, applications, and administrative boundaries. 

I'm very happy, in this context, to announce that from now on, all Live ID's will also work as OpenIDs.   

That means the users of 400 million Live ID accounts will be able to log in to a large number of sites across the internet without a further proliferation of passwords – an important step forward for binging reduced password fatigue to the long tail of small sites engaged in social networking, blogging and consumer services.

As the beta progresses, CardSpace will be integrated into the same offering (there is already a separate CardSpace beta for Live ID).

Again, we are stressing choice of protocol and framework.

Beyond this support for a super lightweight open standard, we have a framework specifically tailored for those who want a very lightweight way to integrate tightly with a wider range of Live capabilities.

The Live Framework gives you access to an efficient, lightweight protocol that we use to optimize exchanges within the Live cloud.

It too integrates with our Gateway. Developers can download sample code (available in 7 languages), insert it directly into their application, and get access to all the identities that use the gateway including Live IDs and federated business users connecting via Geneva, the Microsoft Services Connector, and third party Apps.

 

Flexible and Granular Trust Policy

 Decisions about access control and personalization need to be made by the people responsible for resources and information – including personal information. That includes deciding who to trust – and for what.

At Microsoft, our Live Services all use and trust the Microsoft Federation Gateway, and this is helpful in terms of establishing common management, quality control, and a security bar that all services must meet.

But the claims-based model also fully supports the flexible and granular trust policies needed in very specialized contexts. We already see some examples of this within our own backbone.

For example, we’ve been careful to make sure you can use Azure to build a cloud application – and yet get claims directly from a third party STS using a different third party’s identity framework, or directly from OpenID providers. Developers who take this approach never come into contact with our backbone.

Our Azure Access Control Service provides another interesting example. It is, in fact, a security component that can be used to provide claims about authorization decisions. Someone who wants to use the service might want their application, or its STS, to consume ACS directly, and not get involved with the rest of our backbone. We understand that. Trust starts with the application and we respect that.

Still another interesting case is HealthVault. HealthVault decided from day one to accept OpenIDs from a set of OpenID providers who operate the kind of robust claims provider needed by a service handling sensitive information. Their requirement has given us concrete experience, and let us learn about what it means in practice to accept claims via OpenID. We think of it as pilot, really, from which we can decide how to evolve the rest of our backbone.

So in general we see our Identity Backbone and our federation gateway as a great simplifying and synergizing factor for our Cloud services. But we always put the needs of trustworthy computing first and foremost, and are able to be flexible because we have a single identity model that is immune to deployment details.


Identity Software + Services

To transition to the services world, the identity platform must consist of both software components and services components.

We believe Microsoft is well positioned to help developers in this critical area.

Above all, to benefit from the claims-based model, none of these components is mandatory. You select what is appropriate.

We think the needs of the application drive everything. The application specifies the claims required, and the identity metasystem needs to be flexible enough to supply them.

Roadmap

Our roadmap looks like this:

Identity @ PDC

You can learn more about every component I mentioned today by drilling into the 7 other presentations presented at PDC (watch the videos…):

Software
(BB42) Identity:  “Geneva” Server and Framework Overview
(BB43) Identity: “Geneva” Deep Dive
(BB44) Identity: Windows CardSpace “Geneva” Under the Hood
Services
(BB22) Identity: Live Identity Services Drilldown
(BB29) Identity: Connecting Active Directory to Microsoft Services
(BB28) .NET Services: Access Control Service Drilldown
(BB55) .NET Services: Access Control In the Cloud Services
 

Conclusion

I once went to a hypnotist to help me give up smoking. Unfortunately, his cure wasn’t very immediate. I was able to stop – but it was a decade after my session.

Regardless, he had one trick I quite liked. I’m going to try it out on you to see if I can help focus your take-aways from this session. Here goes:

I’m going to stop speaking, and you are going to forget about all the permutations and combinations of technology I took you through today. You’ll remember how to use the claims based model. You’ll remember that we’ve announced a bunch of very cool components and services. And above all, you will remember just how easy it now is to write applications that benefit from identity, through a single model that handles every identity use case, is based on standards, and puts users in control.

 

Project Geneva – Part 4

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

We have another announcement that really drives home the flexibility of claims.

Today we are announcing a Community Technical Preview (CTP) of the .Net Access Control Service, an STS that issues claims for access control. I think this is especially cool work since it moves clearly into the next generation of claims, going way beyond authentication. In fact it is a claims transformer, where one kind of claim is turned into another.

An application that uses “Geneva” can use ACS to externalize access control logic, and manage access control rules at the access control service.  You just configure it to employ ACS as a claims provider, and configure ACS to generate authorization claims derived from the claims that are presented to it. 

The application can federate directly to ACS to do this, or it can federate with a “Geneva” Server which is federated with ACS.

ACS federates with the Microsoft Federation Gateway, so it can also be used with any customer who is already federated with the Gateway.

The .Net Access Control Service was built using the “Geneva” Framework.  Besides being useful as a service within Azure, it is a great example of the kind of service any other application developer could create using the Geneva Framework.

You might wonder – is there a version of ACS I can run on-premises?   Not today, but these capabilities will be delivered in the future through “Geneva”.

Putting it all together

Let me summarize our discussion so far, and then conjure up Vittorio Bertocci, who will present a demo of many of these components working together.

  • The claims-based model is a unified model for identity that puts users firmly in control of their identities.
  • The model consists of a few basic building blocks can be put together to handle virtually any identity scenario.
  • Best of all, the whole approach is based on standards and works across platforms and vendors.

Let’s return to why this is useful, and to my friend Joe.  Developers no longer have to spend resources trying to handle all the demands their customers will make of them with respect to identity in the face of evolving technology. They no longer have to worry about where things are running. They will get colossal reach involving both hundreds of millions of consumers and corporate customers, and have complete control over what they want to use and what they don’t.

Click on this link – then skip ahead about 31 Minutes – and my friend Vittorio will take you on a whirlwind tour showing all the flexibility you get by giving up complexity and programming to a simple, unified identity model putting control in the hands of its users.  Vitorrio will also be blogging in depth about the demo over the next little while.  [If your media player doesn't accept WMV but understands MP4, try this link.]

In the next (and thankfully final!) installment of this series, I'll talk about the need for flexibility and granulartiy when it comes to trust, and a matter very important to many of us – support for OpenID.

Project Geneva – Part 3

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

Microsoft also operates one of the largest Claims Providers in the world – our cloud identity provider service, Windows Live ID.

It plays host to more than four hundred million consumer identities.

In the Geneva wave, Live ID will add “managed domain” services for sites and customers wanting to outsource their identity management.  With this option, Live would take care of identity operations but the sign in/sign up UX can be customized to fit the look of your site.

But in what I think is an especially exciting evolution, Live IDs also get access to our cloud applications and developer services via the gateway, and are now part of the same open, standards-based architecture that underlies the rest of the Geneva Wave.

Microsoft Services Connector

Some customers may want to take advantage of Microsoft’s cloud applications, hosting, and developer services – and have Active Directory – but not be ready to start federating with others.

We want to make it very easy for people to use our cloud applications and developer services without having to make any architectural decisions.  So for that audience, we have built a fixed function server to federate Active Directory directly to the Microsoft Federation Gateway.

This server is called the Microsoft Services Connector (MSC).   It was built on Project Geneva technology.

Since it’s optimized for accessing Microsoft cloud applications it manages a single trust relationship with the Federation Gateway.  Thus most of the configuration is fully automated.  We think the Microsoft Services Connector will allow many enterprises to start working with federation in order to get access to our cloud, and that once they see the benefits, they’ll want to upgrade their functionality to embrace full federation through Geneva Server and multilateral federation.

Through the combination of Geneva Framework and Server, Microsoft Services Connector, Live ID, the Microsoft Federation Gateway – and the ability to use CardSpace to protect credentials on the Internet -millions of Live and AD users will have easy, secure, SSO access to our cloud applications and developer services.

But what about YOUR applications?

OK.  This is all very nice for Microsoft's apps, but how do other application developers benefit?

Well, since the Federation Gateway uses standard protocols and follows the claims-based model, if you write your application using a framework like “Geneva”, you can just plug it into the architecture and benefit from secure, SSO access by vast numbers of users – ALL the same users we do.  The options open to us are open to you.

This underlines my conviction that Microsoft has really stepped up to the plate in terms of federation.  We haven't simply made it easier for you to federate with US in order to consume OUR services.  We are trying to make you as successful as we can in this amazing new era of identity.  The walled garden is down.  We want to move forward with developers in a world not constrained by zero sum thinking.

Configure your application to accept claims from the Microsoft Federation Gateway and you can receive claims from Live ID and any of the enterprise and government Federation Gateway partners who want to subscribe to your service.  Or ignore the MFG and connect directly to other enterprises and other gateways that might emerge.  Or connect to all of us.

Crossing organizational boundaries

If this approach sounds too good to be true, some of you may wonder whether, to benefit from Microsoft's identity infrastructure, you need to jump onto our cloud and be trapped there even if you don't like it!

But the claims-based model moves completely beyond any kind of identity lock-in.  You can run your application whereever you want – on your customer's premise, in some other hosting environment, even in your garage.  You just configure it to point to the Microsoft Federation Gateway – or any other STS – as a source of claims.

These benefits are a great demonstration of how well the claims model spans organizational boundaries.  We really do move into a “write once and run anywhere” paradigm. 

Do you want choice or more choice?

For even more flexibility, you can use an enterprise-installed “Geneva” server as your application's claim source, and configure that server to accept claims from a number of gateways and direct partners.

In the configuration shown here, the Geneva server can accept claims both hundreds of millions of Live ID users and from a partner who federates directly.

Claims-based access really does mean applications are written once, hosted anywhere.  Identity source is a choice, not a limitation.

You get the ability to move in and out of the cloud at any time and for any reason.

Even more combinations are possible and are just a function of application configuration. It’s a case of “Where do you want to get claims today?”.   And the answer is that you are in control.

In the next installment of this presentation I'll tell you about another service we are announcing – again a claims-based service but this time focussing on authorization.  I'll also link to the demo, by Vittorio Bertocci, of how all these things fit together.

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.

The Identity Metasystem and its Identity Selectors

Paul Madsen at ConnectID makes a good point in his “Could someone hand me that hammer please?

I have a dead horse here that needs some beating.

Does  ‘identity metasystem’ not imply “a pluralism of operators and technologies”? Isn't this even almost a law?

If so, should a TC focused on a single (albeit important) identity technology claim within its name the ‘meta’ scope?

The OASIS Identity Metasystem Interoperability (IMI) Technical Committee will work to increase the quality and number of interoperable implementations of Information Cards

The IMI TC's mandate respects the ‘pluralism of operators’ required by the metasystem definition, but not the other piece.

NB: Any comment that includes any combination of  ‘forgot SAML token’ will be summarily rejected.

 

Metasystem and Identity Selector

Paul is completely right that the Identity Metasystem is a unifying model intended to bring together many contributing technologies – including Kerberos, PKI, browser-only federation protocols like SAML, WS-Security, WS-Trust and lightweight protocols like OpenID.  And in fact, reaching across this diversity is the most important thing about it.  Breadth is what allows us, as an industry, to create “one identity model” in terms of application development, deployment and most important, user experience.

To make this vision a reality, we need a component of the metasystem that has been missing: a common “Identity Selector”  (early examples being CardSpace and DigitalMe). 

Clearly such an important component needs to evolve in the context of an international standards body, so the announcement of the new OASIS Technical Committee dedicated to Information Cards and their interoperability is an important milestone:

Boston, MA, USA; 23 September 2008 — OASIS, the international open standards consortium, has formed a new group to enable the use of Information Cards to universally manage personal digital identities. The OASIS Identity Metasystem Interoperability (IMI) Technical Committee will work to increase the quality and number of interoperable implementations of Information Cards. A rapidly-developing, Web 2.0-friendly method for shared light authentication, Information Cards let people authenticate themselves on multiple web sites without maintaining passwords for each site.

But back to the name 

While I think Information Cards are beneficial to the whole metasystem, they are not themselves the metasytem, and don't encompass all aspects of its interoperability. 

For this reason, I don't personally think the OASIS committee's name is currently quite right.

I've never personally participated in OASIS or any other standards body (I have great respect for those who do.)  So I have no idea whether it is possible to tweak a name once a committee is formed.  If it didn't turn into a major time-waster, I think doing so would show everyone's respect for all the other contributions being made to the metasystem.  I would prefer a name that is more technically specific, like the OASIS Identity Selector Interoperability Technical Committee (ISI).

The people who put in the effort to set up the committee and come up with a name will rightly say, “I wish you had given us that feedback earlier” – and I accept that criticism.  Maybe I have missed my opportunity to provide feedback.  Basically, I was sufficiently excited about the emergence of the committee, and convinced that the Identity Selector did contribute to Metasystem Interoperability, that the potential issues with the name didn't jump out at me. 

And now to Occam

And now for something completely different.  In a recent post Paul also reveals the origins of the third law of identity, and makes a great connection:

“William of Occam was a 14th century English philosopher, best know for his ‘principle of parsimony‘ in comparing different explanations for some phenomena.

entia non sunt multiplicanda praeter necessitatem

“When translated and applied to identity, it's clear that Kim's Law 3 was preempted by some 700 years

entities must not be multiplied beyond necessity

The Laws of Identity

Thanks to Eric Norman, Craig Burton and others for helping work towards a “short version” of the Laws of Identity. So here is a refinement:

People using computers should be in control of giving out information about themselves, just as they are in the physical world.

The minimum information needed for the purpose at hand should be released, and only to those who need it. Details should be retained no longer than necesary.

It should NOT be possible to automatically link up everything we do in all aspects of how we use the Internet. A single identifier that stitches everything up would have many unintended consequences.

We need choice in terms of who provides our identity information in different contexts.

The system must be built so we can understand how it works, make rational decisions and protect ourselves.

Devices through which we employ identity should offer people the same kinds of identity controls – just as car makers offer similar controls so we can all drive safely.

Crypto flaw + bad practices = need for governance

Speaking of issues of governance, the Register just brought us this report on a recent “archeological investigation” by Ben Laurie and Richard Clayton that revealed how a Linux security flaw left a number of OpenID sites vulnerable to attack:

“Slipshod cryptographic housekeeping left some OpenID services far less secure than they ought to be.

“OpenID is a shared identity service that enables users to eliminate the need for punters to create separate IDs and logins for websites that support the service. A growing number of around 9,000 websites support the decentralised service, which offers a a URL-based system for single sign-on.

“Security researchers discovered the websites run by three OpenID providers – including Sun Microsystems – used SSL certificates with weak crypto keys. Instead of being generated from billions of possibilities, the keys came from a a set of just 32,768 options, due to a flaw in the random number generation routines used by Debian. The bug, which has been dormant on systems for 18 months, was discovered and corrected back in May.

“Keys generated by cryptographically flawed systems still needed to be replaced even after the software was upgraded. But recent research by Ben Laurie of Google reveals that 1.5 per cent of certificates he looked at contained weak keys. Three OpenID providers (openid.sun.com, xopenid.net and openid.net.nz) were among the guilty parties.

“To exploit the vulnerability, malicious hackers would need to trick surfers into visiting a site impersonating a pukka OpenID provider. But faking digital certificate alone wouldn't do the trick without first misdirecting surfers to these bogus sites. Dan Kaminsky's recent discovery of a DNS cache poisoning flaw made it far more plausible to construct an attack that sent surfers the wrong away around the net's address lookup system, potentially to a bogus Open site posing as the real deal.

“The security flaw meant that even cautious users who check SSL certificates were at risk of handing over their OpenID credentials as part of a phishing attack. Such an attack would take a lot of effort to pull off and would only yield OpenID login credentials, which aren't especially useful for hackers and are difficult to monetise.

“Going after online banking credentials via a site that makes no attempt to offer up fake SSL certificates is a far more reliable moneyspinner, a factor that leads noted security researcher Richard Clayton to describe the attack as the “modern equivalent of a small earthquake in Chile”.

“Sun has responded to the issue by generating a new secure key, which reduces the scope for mischief but still leaves potential problems from the old key.

“More thoughts on the cryptographically interesting – though not especially life-threatening – flaw can be found in Clayton's posting on Cambridge University's Light the Blue Touchpaper blog here. A security advisory by Laurie and Clayton explaining the issue in greater depth can be found here.”

I tip my hat to Ben and Richard for doing what I think of as “system archeology” – looking into the systems people actually leave behind them, as opposed to the ones they think they have built.  We need a lot more of this.  In fact, we need to have full time archeologists rigorously exploring what is being deployed.

This said, I have to question the surprisingly opportunistic title of Richard's piece:  An insecurity in OpenID, not many dead.

Let's get real.  None of what went wrong here was in any way specific to OpenID.  The weakness would have struck any application that relied on crypto and was built on Debian Linux and operated in the same way.  This includes SSL, which for some reason doesn't get singled out.  And it applies to SAML, WS-Trust and PKI  (e.g. any of the security-based identity protocols).  Is OpenID a convenient straw man? 

In fact there were really two culprits.  First, the crypto flaw itself, a problem in Linux.  Second, the fact that although the flaw had been fixed, new keys and certificates had not been obtained by a number of the operators. 

So we are brought right back to the issue of governance, and in all fairness, Richard makes that point too.  Given the improper operating practices, and the fact that OpenID imples no contractual agreement, how would anyone have been able to sort out liability if the flaw had resulted in a serious breach?

Clearly, timely patching of one's operating system needs to be one of the host of requirements placed on any identity provider.  A system of governance would make this explicit, and provide a framework for assigning liability should the requirement not be met.  I really think we need to move forward on a broadly inclusive governance conversation.

And finally, just so no one thinks I have gone out of character, let's all note that any user who employed an Information Card to authenticate to the OpenID provider would NOT have had her credentials stolen, in spite of the vulnerability Ben and Richard have documented.