Southworks seeds open source claims transformer

Reading Matias Woloski's blog I see that Southworks has put its work bridging OpenID and WS-Federation into an open source project (download here).    This is a great move.  He also shows some screen shots that give a good feel for what was involved in the Medtronics proof of concept described here.  Matias writes:

A year ago I wrote a blog post about how to use the Windows Identity Foundation with OpenID. Essentially the idea was writing an STS that can speak both protocol WS-Federation and OpenID, so your apps can keep using WIF as the claims framework, no matter what your Identity Provider is. WS-Fed == enterprise, OpenID == consumer…

Fast forward to May this year, I’m happy to disclose the proof of concept we did with the Microsoft Federated Identity Interop group (represented by Mike Jones), Medtronic and PayPal. The official post from the Interoperability blog includes a video about it and Mike also did a great write up

The business scenario brought by Medtronic is around an insulin pump trial. In order to register to this trial, users would login with PayPal, which represents a trusted authority for authentication and attributes like shipping address and age for them. Below are some screenshots of the actual proof of concept:

image

image

image

image

While there are different ways to solve a scenario like this, we chose to create an intermediary Security Token Service that understands the OpenID protocol (used by PayPal), WS-Federation protocol and SAML 1.1 tokens (used by Medtronic apps). This intermediary STS enables SSO between the web applications, avoiding re-authentication with the original identity provider (PayPal).

Also, we had to integrate with a PHP web application and we chose the simpleSAMLphp library. We had to adjust here and there to make it compatible with ADFS/WIF implementation of the standards. No big changes though.

We decided together with the Microsoft Federated Identity Interop team to make the implementation of this STS available under open source using the Microsoft Public License.

And not only that but also we went a step further and added a multi-protocol capability to this claims provider. This is, it’s extensible to support not only OpenID but also OAuth and even a proprietary authentication method like Windows Live.

image

 

 

DISCLAIMER: This code is provided as-is under the Ms-PL license. It has not been tested in production environments and it has not gone through threats and countermeasures analysis. Use it at your own risk.

Project Home page
http://github.com/southworks/protocol-bridge-claims-provider

Download
http://github.com/southworks/protocol-bridge-claims-provider/downloads

Docs
http://southworks.github.com/protocol-bridge-claims-provider

If you are interested and would like to contribute, ping us through the github page, twitter @woloski or email matias at southworks dot net

This endeavor could not have been possible without the professionalism of my colleagues: Juan Pablo Garcia who was the main developer behind this project, Tim Osborn for his support and focus on the customer, Johnny Halife who helped shaping out the demo in the early stages in HTML :), and Sebastian Iacomuzzi that helped us with the packaging. Finally, Madhu Lakshmikanthan who was key in the project management to align stakeholders and Mike who was crucial in making all this happen.

Happy federation!

Using Consumer Identities for Business Interactions

Mike Jones writes about an “identity mashup” that drives home a really important lesson:  the organizational and technical walls that used to stand in the way of Internet business are dissolving before our very eyes.  The change agent is the power of claims.  The mashup Mike describes crosses boundaries in many dimensions at once:

  • between industries (medical, financial, technical)
  • between organizations (Medtronic, PayPal, Southworks, Microsoft)
  • between protocols (OpenID and SAML)
  • between computing platforms (Windows and Linux)
  • between software products (Windows Identity Foundation, DotNetOpenAuth, SimpleSAMLphp)
  • between identity requirements (ranging from strong identity verification to anonymous comment)

This is a super-concrete demonstration of the progress being made on the “Identity Metasystem” so many of us in the industry have been working on.   My favorite word in Mike's piece is “quickly”, to which I have taken the liberty of adding my own emphasis:

Medtronic, PayPal, Southworks, and Microsoft recently worked together to demonstrate the ability for people to use their PayPal identities for participating in a Medtronic medical device trial, rather than having to create yet another username and password. Furthermore, the demo showed the use of verified claims, where the name, address, birth date, and gender claims provided by PayPal are relied upon by Medtronic and its partners as being sufficiently authoritative to sign people up for the trial and ship them the equipment. I showed this to many of you at the most recent Internet Identity Workshop.

From a technology point of view, this was a multi-protocol federation using OpenID and WS-Federation – OpenID for the PayPal identities and WS-Federation between Medtronic and two relying parties (one for ordering the equipment and one for anonymously recording opinions about the trial). It was also multi-platform, with the Medtronic STS running on Windows and using the Windows Identity Foundation (WIF) and DotNetOpenAuth, the equipment ordering site running on Linux and using simpleSAMLphp, and the opinions site running on Windows and also using WIF. A diagram of the scenario flows is as follows:

Identity Mash-Up Diagram

We called the demo an “identity mash-up” because Medtronic constructed a identity for the user containing both claims that came from the original PayPal identity and claims it added (“mashed-up”) to form a new, composite identity. And yet, access to this new identity was always through the PayPal identity. You can read more about the demo on the Interoperability @ Microsoft blog, including viewing a video of the demo. Southworks also made the documentation and code for the multi-protocol STS available.

I’ll close by thanking the teams at PayPal, Medtronic, and Southworks for coming together to produce this demo. They were all enthusiastic about using consumer identities for Medtronic’s business scenario and pitched in together to quickly make it happen.

 

New prototype could really help OpenID

I've sometimes been of two minds about OpenID.  I've always seen it as alluring because of its simplicity and openness.  It seemed perfect for simple web applications.

But in my darker moments, I worried about some of the system's usability and security issues.  In particular, I was concerned about how easy it would be for an “evil site” to trick users into going to a web site that looks identical to their OpenID provider, convincing them to log in, and then stealing their credentials.  If this were to happen, everything that is good about OpenID would turn into something negative.

OpenID has become a key part of the Identity Metasystem

I think many of us involved with the OpenID community came to the same conclusions, but felt that if we kept trying to move adoption forward, we'd be able to figure out how to solve the problems.  In the last year, OpenID has without doubt become the most widely adopted system for reusable internet identity.  Adoption by destination sites continues to grow dramatically: approximately 50,000 sites as of July 1, 2009.  The big Internet properties like Google, Yahoo, AOL, MySpace, and Windows Live have become (or are becoming) OpenID Providers.   As a result, the vast majority of the online US population has an account that can be used to log in at the growing number of destination sites. 

Maybe even more important, some of these sites are of the kind that can quickly change perception and behavior. 

Most notable is Facebook, which took a huge step forward when it started accepting OpenIDs for login – blowing away the old saw that “no one wants to be a relying party”. 

Now, the US Government has decided to adopt OpenID as one of the identity protocols for citizen interaction – again, as Relying Party, not Identity Provider.

Sea Change

There is a sea-change here.  I strongly believe the right thing to do is get  behind OpenID as part of the Identity Metasystem, help promote adoption, and work with the community to make it safer and easier to use.  What is encouraging is that the community has repeatedly shown its ability to evolve as it deploys, and has been able to rapidly extend the standard from the inside.   It has now become widely recognized in the industry that active client software (also called an “Identity Selector”) for OpenID could solve most of its problems, given some minor revisions or additions to the protocol.  By remembering the identities you use, this kind of software can address two sets of issues:

  • Usability:  Lets you bring your identities with you to the site, rather than the site having to guess what identities you have
  • Security:  Protects you from being sent to a malicious site impersonating a real site that would steal your password

New prototype at IIW

Yesterday at the OpenID Summit hosted by Yahoo, Microsoft's Mike Jones and Ariel Gordon  showed some of the work their team has been doing to help figure out how this kind of capability could work.  What's cool is that the client they were showing is completely optional – without it, OpenID continues to work as it currently does.  But with it, experience improves and the dangers are greatly reduced.  I agree with them that demand for a better and safer OpenID user experience will drive selector adoption, which will in turn enable scenarios at higher levels of assurance than are possible with OpenID today.

Ariel Gordon, the main UX designer, told me, “I see it as a starting point for joint work with others in the community – definitely not a finished solution or product.”

It is consistent with the Information Card metaphor:

  • Your OpenIDs are shown as visual cards
  • You select an OpenID by clicking
  • The OpenID last used at the site is the default selection

New OpenIDs can be added on the fly, by picking one from a list suggested by the site, or by typing the provider’s URL.

Mike made a good point about what this means for people who use smaller OpenID providers:  “The cool thing is that it remembers the OpenIDs you’ve used and where you used them […] With a web-based Nascar user interface, Arizona Sate University users will never get the same user experience that Google.com users get […]”

Good Tweets

Unfortunately I couldn't attend the meeting in person but remained wired to the tweets.  Summit host Allen Tom from Yahoo said, “Showing already used OpeniIDs is a great protection against phishing: if a rogue RP tries to send the user to ‘fake yahoo.com’, a regular Yahoo user will click on his Yahoo button in the selector and won’t even see the fake yahoo link.”

He added, “The prototype selector goes in the right direction by offering a better experience when present, while not preventing users to access their favorite sites from any computer.”

Google's Eric Sachs saw value too. “…And a fake yahoo tile would say “never used here” so that’s even more information to help protect the user.”

Bringing our perceptions together from different organizations with different missions and  vantage points is what can make all of this succeed. The partnering is the key.

So one of the best things about the prototype, in my view, is that it has already demonstrated collaboration between a whole set of really experienced community members:

  • Relying Parties: JanRain, Plaxo, Deutsche Telekom
  • OpenID Providers: Yahoo, Google, JanRain
  • Identity Selectors: Microsoft, Deutsche Telekom
  • Enhancing Specifications: Microsoft, Facebook, Yahoo. 

Today, the same prototype was presented to the influential Internet Identity Workshop .  I'll add to my growing lis of IOU's a promise to do a screen capture of how the prototype works so everyone can take a look.

More news about our identity team

After my last post, it occurred to me that people would probably be interested in knowing about some of the other figures from the identity community who have joined my colleagues and I to work on identity and access – great people with diverse backgrounds who bring new depth to the increasingly important area of identity and access management. 

I'm going to break this up across several posts in order to keep things manageable…

Ariel Gordon

Ariel Gordon came to Microsoft recently from Orange / France Telecom.  It's really key for the Identity group at Microsoft to have the best possible relationships with our colleagues in the Telecom sector, and Ariel's 12 years of experience and understanding of Telecom will move our dialog forward tremendously. 

Ariel led the creation and deployment of Orange's consumer Identity Management system, focusing  his staff on optimizing customer journeys and UX through Identity lifecycles.  The system currently hosts tens of millions of user identities across Europe.  

Ariel oversaw marketing work (and the development of business planning) for Identity Management and other Enablers, including User Privacy and API exposition framework.  As a key spokesperson for Orange, he unveiled several of their innovations at Industry Events including their support of OpenID and SAML for Outbound Federation at “DIDW” in Sept 2007, and support of OpenID and LiveID for Inbound Federation at “the European Identity Conference” in April 2008.

Orange played an important role in Liberty Alliance, and Ariel has a lot to share with us about Liberty's accomplishments.   Listen to Kuppinger Cole's Felix Gaehtgens interview Ariel on YouTube to get a real sense for his passion and accomplishments.

Pete Rowley

Many people around Internet Identity Workshop know Pete Rowley, not only for the work he has done but because he has a coolio rock-star-type web page banner and a real stone fence:

Pete has been working on identity since the mid 90’s. He contributed to the Netscape Directory Server. Later at Centrify he worked on connecting heterogeneous systems to the Active Directory infrastructure for authentication and policy applications.  Many of us met him at the Identity Gang meetings while he worked for Red Hat. There he founded the Free IPA (Identity, Policy, Audit) open source project. I remember being impressed by what he was trying to achieve:

“For efficiency, compliance and risk mitigation, organizations need to centrally manage and correlate vital security information including

  • Identity (machine, user, virtual machines, groups, authentication credentials)
  • Policy (configuration settings, access control information)
  • Audit (events, logs, analysis thereof)

“Because of its vital importance and the way it is interrelated, we think identity, policy, and audit information should be open, interoperable, and manageable. Our focus is on making identity, policy, and audit easy to centrally manage for the Linux and Unix world. Of course, we will need to interoperate well with Windows and much more.

Now he's working on evolving the Identity Lifecycle Manager (ILM).

Mark Wahl

Mark Wahl has been well known to identerati ever since the early days of LDAP.  In 1997 he published RFC2251, the famous Lightweight Directory Access Protocol (V3) Specification with Tim Howes and Steve Kille.  Of course it was fundamental to a whole generation of directory technology.

People from the directory world may remember Mark as Senior Directory Architect at Innosoft International, and co-founder and President of Critical Angle.  This was great stuff – his  identity management, directory, PKI, messaging and network middleware systems were deployed at many large enterprises and carriers.

Mark was also a Senior Staff Engineer and Principal Directory Architect at Sun Microsystems,  and later  developed and taught a one-year course on information assurance and computer security auditing at the University of Texas.

His passion for auditing and risk assessment technologies for the enterprise identity metasystem led him to create a startup called Informed Control.  You get a good feeling for his thorough and no-holds-barred commitment by browsing through the  site.

Mark is now applying his creativity to evolving the vision, roadmap and architecture for the convergence of identity and security lifecycle management products.

[To be continued…]

Dick Hardt joins Microsoft's Identity Team

John Fontana from Network World has picked up on one of the big deals in my life recently – Dick Hardt is joining our team at Microsoft.  John Fontana posted this in Network World

Noted identity innovator Dick Hardt has agreed to join Microsoft to help the company shape its identity platform.

Hardt, one of the unique personalities in the busy identity community and a vocal Identity 2.0 advocate, will have the title “partner architect” and will be working on consumer, enterprise and government identity problems, he said on his blog

Hardt said he was recruited by Microsoft because he is an “independent thinker.” Microsoft has benefited greatly from the work of other independent thinkers notably identity architect Kim Cameron, who has been instrumental in evolving the company's identity platform and its integration with other vendors, protocols and tools.

“I think the hiring of Dick Hardt is another proof point that Microsoft is serious about identity,” said Jackson Shaw, senior director of product management for Active Directory and integration solutions at Quest Software. “I believe it is also a further sign that Microsoft wants to avoid a Microsoft-centric ‘Passport’ type solution. They are, quite clearly, thinking much bigger – Azure, Geneva and CardSpace are on their way or already delivered so we know they are serious. Dick, along with Kim Cameron and others at Microsoft, will further help to ensure that Microsoft ‘thinks big’ in this important area.”

Hardt, whose reputation is that of an entrepreneur, said on his blog: “I view the opportunity to come in at a senior level and learn how big enterprise and big software works a great learning experience. I'm also excited about changes that are afoot at Microsoft such as Azure and to work beside a bunch of really smart people!”

He also said he relished the opportunity to come in and work with his “Foo Camp friends Jon Udell, Dana Boyd and of course Ray Ozzie.” Foo Camp is an annual hacker event put on by O'Reilly Media.

Hardt, most recently the chair of Sxipper, a position he will retain, comes in at a time when Microsoft is working to marry its newly minted Geneva identity strategy with its services push.

Sxipper was a spin-off from Sxip Identity, where Hardt first began to gain notice in the identity community with his rapid-fire Identity 2.0 presentation. Sixp Identity developed a technology called Sxip Access, which Google used as the foundation of a single sign-on bridge to corporate directories. Sxip later sold the technology to Ping Identity

In addition to his identity background, Hardt also has worked extensively with open source. He founded ActiveState in 1997 and developed tools for open source programming languages, and he ported the Perl programming language to Windows. 

In February, he showed off for the first time his newest work to create “address book 2.0,” a social networking “flow application” that presents a user's contact data in context with what they are viewing on the Internet.

There has never been a better presentation on identity than Dick's presentation on Identity 2.0.  He has played a pivotal role as a catalyst and contributed great thinking and technical ideas to the identity community as an important figure in OpenID.   It's exciting to think that we'll be working together more closely – I have no doubt that Microsoft will be a good place for him to continue all the good work he has beein doing, as a key figure in moving user-centric identity forward as fast as possible.
 

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.

 

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

Clarification

In response to my post earlier today on some OpenID providers who did not follow proper procedures to recover from a bug in Debian Linux, a reader wrote:

 

“You state that users who authenticated to the OpenID provider using an Information Card would not have their credentials stolen.   I assume that cracking the provider cert would allow the bad guys to tease a password out of a user, and that InformationCards require a more secure handshake than just establishing a secure channel with a cert. But it still seems that if the bad guys went to the effort of implementing the handshake, they could fool CardSpace as well. Why does that not expose the users credentials?

 

I'll try to be be more precise.  I should have stayed away from the word “credential”.  It confused the issue.

 

Why?  There are two different things involved here that people call “credentials”.  One is the “credential” used when a user authenticates to an OpenID provider.  To avoid the “credential” word, I'll call this a “primordial” claim: a password or a key that isn't based on anything else, the “first mover” in the authentication chain.

 

The other thing some call a “credential” is the payload produced by the OpenID provider and sent to the relying party.  At the minimum this payload asserts that a user has a given OpenID URL.  Using various extensions, it might say more – passing along the user's email address for instance.  So I'll call these “substantive” claims – claims that are issued by an identity provider and have content.  This differentiates them from primordial ones.

 

With this vocabulary I can express my thoughts more clearly.  By using a self-issued Information card like I employ with my OpenID provider –  which is based on strong public key cryptography – we make it impossible to steal the primordial claim using the attack described.  That is because the secret is never released, even to the legitimate provider.  A proof is calculated and sent – nothing more.

 

But let's be clear:  protecting the primordial claim this way doesn't prevent a rogue identity provider who has guessed the key of a legitimate provider – and poisoned DNS  – from tricking a relying party that depends on its substantitve claim.   Once it has the legitimate provider's key, it can “be” the legitimate provider.  The Debian Linux bug made it really easy to guess the legitimate provider's key.

 

Such a “lucky” rogue provider has “obtained” the legitimate provider's keys.  It can then “manufacture” substantive claims that the legitimate provider would normally only issue for the appropriate individual.  It's like the difference between stealing someone's credit card, and stealing a machine that can manufacture a duplicate of their credit card – and many others as well. 

 

So my point is that using Information Cards would have protected the primordial claim from the vulnerability described.  It would have prevented the user's keys from being stolen and reused.  But It would not have prevented the attack on the substantive claim even in the case of PKI, SAML or WS-Federation.  A weak key is a weak key.

 

The recently publicised wide-scale DNS-poisoning exploits do underline the fact that OpenID isn't currently appropriate for high value resources.  As I explained in more detail here back in February:

 

My view is simple.  OpenID is not a panacea.  Its unique power stems from the way it leverages DNS – but this same framework sets limits on its potential uses.  Above all, it is an important addition to the spectrum of technologies we call the Identity Metasystem, since it facilitates integration of the “long tail” of web sites into an emerging identity framework. 

 

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.   

 

New York Times on OpenID and Information Cards

Randall Stross has a piece in the NYT that hits the jackpot in explaining to non-technical readers what's wrong with passwords and how Information Cards help:    

“I once felt ashamed about failing to follow best practices for password selection — but no more. Computer security experts say that choosing hard-to-guess passwords ultimately brings little security protection. Passwords won’t keep us safe from identity theft, no matter how clever we are in choosing them.

“That would be the case even if we had done a better job of listening to instructions. Surveys show that we’ve remained stubbornly fond of perennial favorites like “password,” “123456” and “LetMeIn.” The underlying problem, however, isn’t their simplicity. It’s the log-on procedure itself, in which we land on a Web page, which may or may not be what it says it is, and type in a string of characters to authenticate our identity (or have our password manager insert the expected string on our behalf).

“This procedure — which now seems perfectly natural because we’ve been trained to repeat it so much — is a bad idea, one that no security expert whom I reached would defend.”

“The solution urged by the experts is to abandon passwords — and to move to a fundamentally different model, one in which humans play little or no part in logging on. Instead, machines have a cryptographically encoded conversation to establish both parties’ authenticity, using digital keys that we, as users, have no need to see.

“In short, we need a log-on system that relies on cryptography, not mnemonics.

“As users, we would replace passwords with so-called information cards, icons on our screen that we select with a click to log on to a Web site. The click starts a handshake between machines that relies on hard-to-crack cryptographic code…”

Randall's piece also drills into OpenID.  Summarizing, he sees it as a password-based system, and therefore a diversion from what's really important:

“OpenID offers, at best, a little convenience, and ignores the security vulnerability inherent in the process of typing a password into someone else’s Web site. Nevertheless, every few months another brand-name company announces that it has become the newest OpenID signatory. Representatives of Google, I.B.M., Microsoft and Yahoo are on OpenID’s guiding board of corporations. Last month, when MySpace announced that it would support the standard, the nonprofit foundation OpenID.net boasted that the number of “OpenID enabled users” had passed 500 million and that “it’s clear the momentum is only just starting to pick up.”

“Support for OpenID is conspicuously limited, however. Each of the big powers supposedly backing OpenID is glad to create an OpenID identity for visitors, which can be used at its site, but it isn’t willing to rely upon the OpenID credentials issued by others. You can’t use Microsoft-issued OpenID at Yahoo, nor Yahoo’s at Microsoft.

“Why not? Because the companies see the many ways that the password-based log-on process, handled elsewhere, could be compromised. They do not want to take on the liability for mischief originating at someone else’s site.

Randall is right that when people use passwords to authenticate to their OpenID provider, the system is vulnerable to many phishing attacks.  But there's an important point to be made:  these problems are caused by their use of passwords, not by their use of OpenID. 

When people authenticate to OpenID in a reliable way – for example, by using Information Cards –  the phishing attacks are no longer possible, as I explain in this video.  At that point, it becomes a safe and convenient way to use a public personna.

The question of whether and when large sites will accept the OpenIDs issued by other large sites is a more complicated one.  I discussed a number of the issues here.   The problem is that for many applications, there needs to be a layer of governance on top of the identity basic technology.  What happens when something goes wrong?  Are there reliability and quality of service guarantees?  If informaiton is leaked, who is responsible?  How is fiscal liability established?  And by the way, we need to figure this out in order to use any federation technology, whether OpenID, SAML or WS-Trust.

So far, these questions are being answered on an ad hoc basis, since there are no established frameworks.  I think you can divide what's happening into two approaches, both of which make a lot of sense: 

First, there are relying parties that limit the use of OpenID to low-value resources.  A great example is the French telecom company Orange.  It will accept ID's from any OpenID provider – but just for free services.  The approach is simply to limit use of the credentials to so-called low-value resources.  Blogger and others use this approach as well.

Second, the is the tack of using the protocol for higher-value purposes, but limiting the providers accepted to those with whom a governance agreement can be put in place.  Microsoft's Health Vault, for example, currently accepts OpenIDs from two providers, and plans to extend this as it understands the governance issues better.  I look at it as a very early example of a governance-oriented approach.

I strongly believe OpenID moves identity forward.  The issues of password attacks don't go away – in fact the vulnerabilites are potentially worse to the extent that a single password becomes the gate to more resources.  But technologies like Information Cards will solve these problems.  There is a tremendous synergy here, and that is the heart of the matter.  Randall writes:

“We won’t make much progress on information cards in the near future, however, because of wasted energy and attention devoted to a large distraction, the OpenID initiative. “

But I think this energy and attention will take us in the right direction as it shines the spotlight on the benefits and issues of identity, wagging identity's “long tail”.