Category: Identity Metasystem

Real business on Geneva

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

More here.

Identity Software + Services Roadmap


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

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

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

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

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

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

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

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

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

 

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…]

Project Geneva – Part 5

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

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

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

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

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

Again, we are stressing choice of protocol and framework.

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

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

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

 

Flexible and Granular Trust Policy

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

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

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

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

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

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

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


Identity Software + Services

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

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

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

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

Roadmap

Our roadmap looks like this:

Identity @ PDC

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

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

Conclusion

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

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

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

 

Project Geneva – Part 4

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

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

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

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

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

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

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

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

Putting it all together

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

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

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

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

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

Project Geneva – Part 3

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

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

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

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

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

Microsoft Services Connector

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

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

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

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

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

But what about YOUR applications?

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

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

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

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

Crossing organizational boundaries

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

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

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

Do you want choice or more choice?

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

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

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

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

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

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

Project Geneva – Part 2

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

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

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

Enterprise Federation

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

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

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

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

Code name Geneva

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

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

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

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

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

The fatal flaw

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

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

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

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

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

Does Microsoft practice what it preaches?

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

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

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

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

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

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

What about Live ID?

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

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.}

 

The Identity Metasystem and its Identity Selectors

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

I have a dead horse here that needs some beating.

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

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

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

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

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

 

Metasystem and Identity Selector

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

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

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

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

But back to the name 

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

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

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

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

And now to Occam

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

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

entia non sunt multiplicanda praeter necessitatem

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

entities must not be multiplied beyond necessity

The Laws of Identity

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

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

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

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

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

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

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