Security and ContactPoint: perception is all

Given the recent theft of my identity while it was being “stewarded” by CountryWide, I feel especially motivated to share with you this important piece on ContactPoint by Sir Bonar Neville-Kingdom GCMG KCVO that appeared in Britain's Ideal Government.   Sir Bonar writes:

I’m facing a blizzard of Freedom of Information requests from the self-appointed (and frankly self-righteous) civil liberties brigade about releasing details of the ContactPoint security review. Of course we’re all in favour of Freedom of Information to a point but there is a limit.

Perhaps I might point out:

The decision not to release any information about the ContactPoint security review was taken by an independent panel. I personally chaired ths panel to ensure its independence from any outside interests. I was of course not directly involved in the original requests, which were handled by a junior staff member.

The security of ContactPoint relies on nobody knowing how it works. If nobody knows what the security measures are, how can they possibly circumvent them? This is simply common sense. Details of the security measures will be shared only with the 330,000 accredited and vetted public servants who will have direct access to the database of children.

We’re hardly going to ask every Tom, Dick and Harry for how to keep our own data secure when, as you’re probably aware, our friends in Cheltenham pretty much invented the whole information security game. To share the security details with some troublemaking non-governmental organisation is merely to ask for trouble with the news media and to put us all needlessly at risk. The Department will not tolerate such risk and it is clearly not in the public interest to do so.

We did consider whether to redact and release any text.  We concluded that the small amount of text that would result after redacting text that should not be released would be incoherent and without context.  Such a release would serve no public interest.

ContactPoint is both a safe and secure system and I should remind everyone that it is fundamental to its success that it is perceived as such by parents, the professionals that use it and others with an interest in ContactPoint and its contribution to delivering the Every Child Matters agenda. Maintaining this perception of absolute “gold standard” security is why it is so important that nobody should question the security arrangements put in by our contractor Cap Gemini (whom I shall be meeting again in Andorra over the weekend).

We must guard the public mind – and indeed our own minds – against any inappropriate concerns on data security.

All this is set out on the Every Child Matters website, which includes a specific and contextual reference to the ContactPoint Data Security Review.  The content has been recently updated and can be found at: http://www.everychildmatters.gov.uk/deliveringservices/contactpoint/security/

Sending out our policy thinking via the medium of a Web Site is a central plank of the “Perfecting Web 1.0” aspect of our Transformational Government strategy, which is due to be complete in 2015. If interfering busybodies have any other queries about how we propose that children in Britain should be raised and protected I would refer them t that

I might add we never get this sort of trouble from the trade association Intellect, and this is why we find them a pleasure to deal with. And on the foundation of that relationship is our track record of success in government IT projects built.

So put that in your collective pipe and smoke it, naysayers. Now is not the time to ask difficult questions. We have to get on with the job of restoring order.

 

Protecting the Internet through minimal disclosure

Here's an email I received from John through my I-name account:

I would have left a comment on the appropriate entry in your blog, but you've locked it down and so I can't 🙁

I have a quick question about InfoCards that I've been unable to find a clear answer to (no doubt due to my own lack of comprehension of the mountains of talk on this topic — although I'm not ignorant, I've been a software engineer for 25+ years, with a heavy focus on networking and cryptography), which is all the more pertinent with EquiFax's recent announcement of their own “card”.

The problem is one of trust. None of the corporations in the ICF are ones that I consider trustworthy — and EquiFax perhaps least of all. So my question is — in a world where it's not possible to trust identity providers, how does the InfoCard scheme mitigate my risk in dealing with them? Specifically, the risk that my data will be misused by the providers?

This is the single, biggest issue I have when it comes to the entire field of identity management, and my fear is that if these technologies actually do become implemented in a widespread way, they will become mandatory — much like they are to be able to comment on your blog — and people like me will end up being excluded from participating in the social cyberspace. I am already excluded from shopping at stores such as Safeway because I do not trust them enough to get an affinity card and am unwill to pay the outrageous markup they require if you don't.

So, you can see how InfoCard (and similar schemes) terrify me. Even more than phishers. Please explain why I should not fear!

Thank you for your time.

There's a lot compressed into this note, and I'm not sure I can respond to all of it in one go.  Before getting to the substantive points, I want to make it clear that the only reason identityblog.com requires people who leave a comment to use an Information Card is to give them a feeling for one of the technologies I'm writing about.  To quote Don Quixote: “The proof of the pudding is the eating.”  But now on to the main attraction. 

It is obvious, and your reference to the members of the ICF illustrates this, that every individual and organization ultimately decides who or what to trust for any given reason.  Wanting to change this would be a non-starter.

It is also obvious that in our society, if someone offers a service, it is their right to establish the terms under which they do so (even requiring identification of various sorts).

Yet to achieve balance with the rights of others, the legal systems of most countries also recognize the need to limit this right.  One example would be in making it illegal to violate basic human rights (for example, offering a service in a way that is discriminatory with respect to gender, race, etc). 

Information Cards don't change anything in this equation.  They replicate what happens today in the physical world.  The identity selector is no different than a wallet.  The Information Cards are the same as the cards you carry in your wallet.  The act of presenting them is no different than the act of presenting a credit card or photo id.  The decision of a merchant to require some form of identification is unchanged in the proposed model.

But is it necessary to convey identity in the digital world?

Increasing population and density in the digital world has led to the embodiment of greater material value there – a tendency that will only become stronger.  This has attracted more criminal activity and if cyberspace is denied any protective structure, this activity will become disproportionately more pronounced as time goes on.  If everything remains as it is, I don't find it very hard to foresee an Internet vulnerable enough to become almost useless.

Many people have come or are coming to the conclusion that these dynamics make it necessary to be able to determine who we are dealing with in the digital realm.  I'm one of them.

However, many also jump to the conclusion that if reliable identification is necessary for protection in some contexts, it is necessary in all contexts.  I do not follow that reasoning. 

Some != All

If the “some == all” thinking predominates, one is left with a future where people need to identify themselves to log onto the Internet, and their identity is automatically made available everywhere they go:  ubiquitous identity in all contexts.

I think the threats to the Internet and to society are sufficiently strong that in the absence of an alternate vision and understanding of the relevant pitfalls, this notion of a singular “tracking key” is likely to be widely mandated.

This is as dangerous to the fabric and traditions of our society as the threats it attempts to counter.  It is a complete departure from the way things work in the physical world.

For example, we don't need to present identification to walk down the street in the physical world.  We don't walk around with our names or religions stenciled on our backs.  We show ID when we go to a bank or government office and want to get into our resources.  We don't show it when we buy a book.  We show a credit card when we make a purchase.  My goal is to get to the same point in the digital world.

Information Cards were intended to deliver an alternate vision from that of a singular, ubiquitous identity.

New vision

This new vision is of identity scoped to context, in which there is minimal disclosure of specific attributes necessary to a transaction.  I've discussed all of this here. 

In this vision, many contexts require ZERO disclosure.  That means NO release of identity.  In other words, what is released needs to be “proportionate” to specific requirements (I quote the Europeans).  It is worth noting that in many countries these requirements are embodied in law and enforced.

Conclusions

So I encourage my reader to see Information Cards in the context of the possible alternate futures of identity on the Internet.  I urge him to take seriously the probability that deteriorating conditions on the internet will lead to draconian identity schemes counter to western democratic traditions.

Contrast this dystopia to what is achievable through Information Cards, and the very power of the idea that identity is contextual.  This itself can be the basis of many legal and social protections not otherwise possible. 

It may very well be that legislation will be required to ensure identity providers treat our information with sufficient care, providing individuals with adequate control and respecting the requirements of minimal disclosure.  I hope our blogosphere discussion can advance to the point where we talk more concretely about the kind of policy framework required to accompany the technology we are building. 

But the very basis of all these protections, and of the very possibility of providing protections in the first place, depends on gaining commitment to minimal disclosure and contextual identity as a fundamental alternative to far more nefarious alternatives – be they pirate-dominated chaos or draconian over-identification.  I hope we'll reach a point where no one thinks about these matters absent the specter of such alternatives.

Finally, in terms of the technology itself, we need to move towards the cryptographic systems developed by David Chaum, Stefan Brands and Jan Camenisch (zero knowledge proofs).    Information Cards are an indispensible component required to make this possible.  I'll also be discussing progress in this area more as we go forward.

 

Leaving a comment

Since one of my goals is to introduce people to Information Cards – and because I used to get mountains of spam comments and worse (!) – I require people to either write to me or use an Information Card when leaving comments on my blog. 

(This blog is hosted for me by Joyent, and it runs on open source software (WordPress, PHP, MySQL, Apache, OpenSolaris).  For Information Card support, it uses Pamelaware, an open-source project offering an Information Card plugin for WordPress and other popular programs.)

Information Cards use an “identity selector”.  Vista has the CardSpace V1 selector built right in.   (If you  don't use Vista please continue here.   Also, if you are wondering about our new beta of Windows CardSpace Geneva – V2 if you want – I'll deal with that in a separate post.)

How you register at my site

1. Click the Information Card logo or the “LOG IN” option in the upper right hand corner of the blog.  (Clicking the logo saves you the step where you can learn about Information Cards).

 

2. If you clicked the logo, go to step 3.  If you have clicked “LOG IN”, you will see this page and can explore the ‘Learn More’ and other tabs.  When ready, click on the Information Card logo to proceed.

 

3. CardSpace will start (it may be a bit slow the first time it loads).  It will verify my site's certificate, and present it t you so you can decide whether or not to proceed.  Click “Yes, choose a card to send”.

 

4.  If you are trying CardSpace for the first time, you don't have a “Managed” card yet.  So just create a “Personal Card” that serves a bit like a username / password – except it can't be phished and protects your privacy by automatically using a different key at every site. 

 

5. You'll be asked to create a Personal card.  Name it with something you'll recognize, and I recommend you put a picture on it (the picture will never be sent).  The name and picture prevent many attacks since if someone tries to fool you with a CardSpace “look-alike”, they won't know what your Cards look like and you will immediately notice your cards aren't present! 

Use an email address that you control – you will have to respond to a confirmation email.  Then click SAVE.

 

 

6.  Now you'll see your saved card, and click SEND.

 

7.  The information from your card will be used to log in to my site, but I'll notice you haven't been here before and send you an email that you must click on to complete registration (I want some way to prevent spammers from bothering me).

 

8.  The email I send looks like the one below.  IMPORTANT NOTE:  this email might be “eaten” by your spam protection software (!) , so don't overlook your spam folder to find it.  (On Hotmail, it doesn't ever get delivered – haven't sorted that out yet.  It doesn't seem to like my little mail server.)  

9.  When you click the embedded link you'll be taken back to my blog as a verification step.  Click on the Information Card logo to log in.

 

10.  CardSpace will come up, and will recognize my site.  Just click send.

 

11.  Et voila…

Press “Go to Blog” and you can leave your comment.

In the future, logging in will just be a two-step process.  Click on the CardSpace logo, click on your personal card, and you will be logged in.  No password to remember.

 

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.

The Identity Domino Effect

My friend Jerry Fishenden, Microsoft's National Technology Officer in the United Kingdom, had a piece in The Scotsman recently where he lays out, with great clarity, many of the concerns that “keep me up at night”.  I hope this kind of thinking will one day be second nature to policy makers and politicians world wide. 

Barely a day passes it seems without a new headline appearing about how our personal information has been lost from yet another database. Last week, the Information Commissioner, Richard Thomas, revealed that the number of reported data breaches in the UK has soared to 277 since HMRC lost 25 million child benefit records nearly a year ago. “Information can be a toxic liability,” he commented.

Such data losses are bad news on many fronts. Not just for us, when it's our personal information that is lost or misplaced, but because it also undermines trust in modern technology. Personal information in digital form is the very lifeblood of theinternet age and the relentless rise in data breaches is eroding public trust. Such trust, once lost, is very hard to regain.

Earlier this year, Sir James Crosby conducted an independent review of identity-related issues for Gordon Brown. It included an important underlying point: that it's our personal data, nobody else's. Any organisation, private or public sector, needs to remember that. All too often the loss of our personal information is caused not by technical failures, but by lackadaisical processes and people.

These widely-publicised security and data breaches threaten to undermine online services. Any organisations, including governments, which inadequately manage and protect users’ personal information, face considerable risks – among them damage to reputation, penalties and sanctions, lost citizen confidence and needless expense.

Of course, problems with leaks of our personal information from existing public-sector systems are one thing. But significant additional problems could arise if yet more of our personal information is acquired and stored in new central databases. In light of projects such as the proposed identity cards programme, ContactPoint (storing details of all children in the UK), and the Communications Data Bill (storing details of our phone records, e-mails and websites we have visited), some of Richard Thomas's other comments are particularly prescient: “The more databases set up and the more information exchanged from one place to another, the greater the risk of things going wrong. The more you centralise data collection, the greater the risk of multiple records going missing or wrong decisions about real people being made. The more you lose the trust and confidence of customers and the public, the more your prosperity and standing will suffer. Put simply, holding huge collections of personal data brings significant risks.”

The Information Commissioner's comments highlight problems that arise when many different pieces of information are brought together. Aggregating our personal information in this way can indeed prove “toxic”, producing the exact opposite consequences of those originally intended. We know, for example, that most intentional breaches and leaks of information from computer systems are actually a result of insider abuse, where some of those looking after these highly sensitive systems are corrupted in order to persuade them to access or even change records. Any plans to build yet more centralised databases will raise profound questions about how information stored in such systems can be appropriately secured.

The Prime Minister acknowledges these problems: “It is important to recognise that we cannot promise that every single item of information will always be safe, because mistakes are made by human beings. Mistakes are made in the transportation, if you like – the communication of information”.

This is an honest recognition of reality. No system can ever be 100 per cent secure. To help minimise risks, the technology industry has suggested adopting proposals such as “data minimisation” – acquiring as little data as required for the task at hand and holding it in systems no longer than absolutely necessary. And it's essential that only the minimum amount of our personal information needed for the specific purpose at hand is released, and then only to those who really need it.

Unless we want to risk a domino effect that will compromise our personal information in its entirety, it is also critical that it should not be possible automatically to link up everything we do in all aspects of how we use the internet. A single identifying number, for example, that stitches all of our personal information together would have many unintended, deeply negative consequences.

There is much that governments can do to help protect citizens better. This includes adopting effective standards and policies on data governance, reducing the risk to users’ privacy that comes with unneeded and long-term storage of personal information, and taking appropriate action when breaches do occur. Comprehensive data breach notification legislation is another important step that can help keep citizens informed of serious risks to their online identity and personal information, as well as helping rebuild trust and confidence in online services.

Our politicians are often caught between a rock and a very hard place in these challenging times. But the stream of data breaches and the scope of recent proposals to capture and hold even more of our personal information does suggest that we are failing to ensure an adequate dialogue between policymakers and technologists in the formulation of UK public policy.

This is a major problem that we can, and must, fix. We cannot let our personal information in digital form, as the essential lifeblood of the internet age, be allowed to drain away under this withering onslaught of damaging data breaches. It is time for a rethink, and to take advantage of the best lessons that the technology industry has learned over the past 30 or so years. It is, after all, our data, nobody else's.

My identity has already been stolen through the very mechanisms Jerry describes.  I would find this even more depressing if I didn't see more and more IT architects understanding the identity domino problem – and how it could affect their own systems. 

It's our job as architects to do everything we can so the next generation of information systems are as safe from insider attacks as we can make them.  On the one hand this means protecting the organizations we work for from unnecessary liability;  on the other, it means protecting the privacy of our customers and employees, and the overall identity fabric of society.

In particular, we need to insist on:

  • scrupulously partitioning personally identifying information from operational and profile data;
  • eliminating “rainy day” collection of information – the need for data must always be justifiable;
  • preventing personally identifying information from being stored on multiple systems;
  • use of encryption;
  • minimal disclosure of identity intormation within a “need-to-know” paradigm.

I particularly emphasize partitioning PII from operational data since most of a typical company's operational systema – and employees – need no access to PII.  Those who do need such access rarely need to know anything beyond a name.  Those who do need greater access to detailed information rarely need access to information about large numbers of people except in anonymized form.

I would love someone to send me a use case that calls for anyone to have access – at the same time – to the personally identifying information about thousands of individuals  (much less millions, as was the case for some of the incidents Jerry describes).  This kind of wholesale access was clearly afforded the person who stole my identity.  I still don't understand why. 

Where is your identity more likely to be stolen?

 From the Economist:

Internet users in Britain are more likely to fall victim to identity theft than their peers elsewhere in Europe and North America. In a recent survey of 6,000 online shoppers in six countries by PayPal and Ipsos Research, 14% of respondents in Britain said that they have had their identities stolen online, compared with only 3% in Germany. More than half of respondents said that they used personal dates and names as passwords, making it relatively easy for scammers to gain access to accounts. The French are particularly cavalier, with two-thirds using easily guessed passwords and over 80% divulging personal data, such as birthdays, on social-networking sites.

Of course, my identity was stolen (and apparently sold) NOT because of inadequate password hygiene, but just because I was dealing with Countrywide – a company whose computer systems were sufficiently misdesigned to be vulnerable to a large-scale insider attack.  So there are a lot of things to fix before we get to a world of trustworthy computing.

 

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.

Project Geneva – Part 1

I always want my blog to be about ideas, not the specific products I work on. 

But I thought it might be useful to make a bit of an exception in terms of sharing the announcements I made this week at the Microsoft Professional Developers Conference in Los Angeles.  I'm hoping this might help others in the industry understand exactly what we at Microsoft been able to accomplish around identity, what's left to do, and where we think we're going.

A number of people have told me that one of the conclusions they drew from the presentation is that when it comes to identity,  big, synergistic, cross-industry things are happening.   I liked that.

Not random things, not proprietary things, not divisive things.  But initiatives that further our collaboration, open standards, user choice and control and the “identity metasystem” many of us believe in so strongly, even if we call it by different names. 

I thought it might help, in particular, to share the conversation we are having with our developers.  This set of posts is intended as a bit of a look behind the curtain – or rather, as pulling back the curtain to show there is no curtain, if you will.  My presentation, which is on video here, went like this…

The first lines of every application

Whether you are creating serious Internet banking systems, hip new social applications, multi-party games or business applications for enterprise and government, you need to know something about the person using your application. We call this identity.

There is no other way to shape your app to the needs of your users, or to know how to hook people up to the resources they own or can share.

I want to be clear. Knowing “something” doesn't mean knowing “everything”.  We want to keep from spewing personal information all over the Internet.  It means knowing what’s needed to provide the experience you are trying to create.

This might sometimes include someone’s name. Or knowing they are really the person with a certain bank account.

Or it might just involve knowing that someone is in a certain role. Or in a certain age bracket.

It also might simply be a question of remembering that some user prefers Britney Spears to New Kids on the Block or Eminem.

Identity Turbulence

But getting identity information is one of the messiest aspects of application development. People are up to their necks in passwords. They use many different mechanisms to establish identity, and its getting worse.

One of my good friends at Microsoft is in charge of the identity aspects of one of our flagship apps. Let’s call him Joe .

He started years ago by building in support for usernames and passwords.  He was supposed to finish up within a few weeks, but soon found he needed a second project to build in better password reset and account management.

This soon worked pretty well, but when presented to customers, no one would deploy in large numbers unless he added a help desk component – so he did.

Then as Active Directory started gaining critical mass, he needed to set up a project to integrate with Active Directory.  When that was finished, the large sites wanted to use AD with multiple forests, and that involved a complete rewrite…

Next, people wanted to use the app outside the firewall, so he needed to add One Time Password (OTP) support. Supporters of Smart Cards were adamant that if OTP was supported, smartcards should work too.

Joe was just pretty much ready to return to his “core work” when he was asked to support SAML. He hadn't even finished his initial investigation of this when people started asking for OpenID support too.  Plus he needed to integrate with another software product by a different vendor  – who used a completely different and proprietary approach to identity.

As he was looking at all this he was hit by phishing attacks. That brought about a whole new round of security reviews – one for every one of the projects just discussed.

Now Joe has realized that his application has to be easily hostable in the cloud as well as work on-premise. And it needs to support delegation so it can access other services on behalf of his users…

So you’ll understand that he really wants and needs a better way. He wants to focus on the core values of his app, not the changing trends in identity.

Claims-based Access

 As we understood more about these problems, and the hardships they were causing developers, we started work on a way to insulate the application from all these issues.

Our goal? You – the developer – would write the application once and be done, yet it would support all the identity requirements customers have as they host it in different environments.

This was the same kind of problem we had in spades in the early days of computing. Back then, you needed to write separate code for each type of disk drive you wanted to support. There was no end to it. If you didn’t support the new drives you’d lose part of your market. So we needed the idea of a logical disk that was always the same.

We can now do the same thing around identity. We use what we call the Claims Based model.

A claim is a statement by one subject about another subject. Examples: someone's email address, age, employer, roles, custumer number, permission to access something.  There are no constraints on the semantics of a claim.

The model starts from the needs of the application:  you write your application on the assumption you can get whatever claims you need.

Then there is a standards-based architecture for getting you those claims. We call it the Identity Metasystem – meaning a system of identity systems. 

 

Here’s how the architecture works. As I said, the application is in control. It specifies the kinds of claims it requires. The claims providers support protocols for issuing claims. You can also pop in claims providers that translate from one claim to another – we call this claims transformers. That makes the system very flexible and open.

The technical name for a claims provider is a “Security Token Service”. You’ll see the abbreviation STS on upcoming slides.

The important thing here is that all existing identity mechanisms can be represented through claims and participate in the metasystem. As an app developer, you just deal with claims. But you get support for all permutations and combinations without getting your hands dirty or even thinking about it.

I say “all” to emphasize something – the open nature of this system. It accepts and produces identities from and for every type of platform and technology – no walled gardens.

You can choose to get your identity from anywhere you wish.  You can choose any framework to build your app.  You can choose to use any client or browser.

What's involved for the developer?

Let me give you an example.  I'll peek ahead and show you how the claims-based model is used in the Geneva Framework – new capabilities within .NET.  Other frameworks would have similar capabilities, though we think our approach is especially programmer-friendly. 

Basically, to answer the “Who are you?” question, you write your app as per normal, and simply add this extra configuration to you app.config file: 

(There are a couple of more cut-and-paste lines needed, to make sure some modules are included, but otherwise that’s it.)

Now, when a user hits your app, if they haven't been authenticated yet, they will get automatically redirected to the claims provider at https://sts1.contoso.com/FederationPassive to pick up their claims.  The claims provider will get your user to authenticate, and if all goes well, will redirect her back to your application with her identity set, and any necessary claims available to your program.  In other words, with zero effort on your part, no unauthenticated user will ever hit your app.  Yet you are completely free to point your app at any claims provider on any platform made by any vendor and located anywhere on the Internet.

To drill into the actual claim values, you use a technique like this:

You’ll see the Thread has a Current Principal, and the Principal has an Identity, so you get a Claims Identity interface as shown, then cycle through the claims or pull out the one you need.  In this case, it is the claim with the type of “role” – in the the enum MyClaimTypes.Role…

If you are an application developer, we've already come to the big takeaway of this presentation.  You can get up and go home now.  Everything else I’m going to show you is just to give you a deeper understanding of all the many use cases and scenarios that can be supported through these mechanisms.

Again, the claims shown in this example are implemented through well accepted industry standards. The same code works with claims that come from anywhere, any platform, any vendor, any operating system, any cloud provider.

Solving problems with claims

{In the next segment, I'll share the ideas I presented to my developer audience about how they could use claims to solve concrete problems.}