Category: Cloud

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

 

Resources have rights too

Paul Madsen has a knack for pithy identity wisdom.  But his recent piece on HealthVault's use of OpenID made me do a double take.

“Simon Willison defends HealthVault‘s choice of OPs [OpenID providers – Kim].

“I disagree. It is I, as a user, that should be able to dictate to HealthVault the OPs from which they are to accept identity assertions through OpenID.

“Just as I, as a user of Vista, should be able to dictate to Microsoft which software partners they work with to bundle into the OS (I particularly like the Slow Down to Crawl install).

“Just as I, as a Zune user … oh wait, there are no Zune users….

“The mechanism by which I (the user) am able to indicate to HealthVault, or Vista, my preferences for their partners is called ‘the market‘.”

Hmmm.  All passion aside, are Vista and HealthVault really the same things?

When you buy an operating system like Vista, it is the substratum of YOUR personal computer.  You should be able to run whatever YOU want on it.  That strikes me as part of the very definition of the PC.

But what about a cloud service like HealthVault?  And here I want to get away from the specifics of HealthVault, and talk generically about services that live in the cloud.  In terms of the points I want to make, we could just as easily be talking about Facebook, LinkedIn, Blogger or Hotmail.

As a user, do you own such a service? Do you run it in whatever way you see fit?  

I've tried a lot of services, and I don't think I've ever seen one that gives you that kind of carte blanche. 

Normally a service provides options. You can often control content, but you function within parameters.  Your biggest decision is whether you want to use the service in the first place.  That's a large part of what “the market” in services really is like.

But let me push this part of the discussion onto “the stack” for a moment.

PUSH

Last week a friend came by and told me a story.  One of his friends regularly used an Internet advertising service, and paid for it via the Internet too.  At some point, a large transaction “went missing”.  The victim contacted the service through which he was making the transaction, and was told it “wasn't their problem”.  Whose problem was it?

I don't know anything about legal matters and am not talking from that point of view.  It just seems obvious to me that if you are a company that values its relationships with customers, this kind of breach really IS your problem, and you need to face up to that.

And there is the rub.  I never want to be the one saying, “Sorry – this is your problem, not ours.”  But if I'm going share the problem, shouldn't I have some say in preventing it and limiting my liability?

POP

I think that someone offering a service has the right to define the conditions for use of the service (let's for now ignore the fact that there may be some regulation of such conditions – for example certain conditions might be “illegal” in some jurisdictions).  And that includes security requirements.

In other words, matters of access control proceed from the resource.  The resource decides who can access it.   Identity assertions are a tool which a resource may use to accomplish this.  For years we've gotten this backwards, thinking access proceeded from the identity to the resource – we need to reverse our thinking.

Takeaway:  “user-centric” doesn't mean The Dictatorship of the Users.  In fact there are three parties whose interests must be accomodated (the user, the resource, and the claims provider).  At times this is going to be complex.  Proclamations like, “It is I, as a user, that should be able to dictate…” just don't capture what is at stake here. 

I like the way Simon Willison puts this:

“You have to remember that behind the excitement and marketing OpenID is a protocol, just like SMTP or HTTP. All OpenID actually provides is a mechanism for asserting ownership over a URL and then “proving” that assertion. We can build a pyramid of interesting things on top of this, but that assertion is really all OpenID gives us (well, that and a globally unique identifier). In internet theory terms, it’s a dumb network: the protocol just concentrates on passing assertions around; it’s up to the endpoints to set policies and invent interesting applications.

“Open means that providers and consumers are free to use the protocol in whatever way they wish. If they want to only accept OpenID from a trusted subset of providers, they can go ahead. If they only want to pass OpenID details around behind the corporate firewall (great for gluing together an SSO network from open-source components) they can knock themselves out. Just like SMTP or HTTP, the protocol does not imply any rules about where or how it should be used…”

In a later post – where he seems to have calmed down a bit – Paul mentions a Liberty framework that allows relying parties to “outsource the assessment of… OPs to accredited 3rd parties (or at least provide a common assessment framework…)”.  This sounds more like the Paul I know, and I want to learn more about his thinking in this area.

Talking about the Identity Bus

During the Second European Identity Conference, Kuppinger-Cole did a number of interviews with conference speakers. You can see these on the Kuppingercole channel at YouTube.

Dave Kearns, Jackson Shaw, Dave Olds and myself had a good old time talking with Felix Gaehtgens about the “identity bus”.  I had a real “aha” during the interview while I was talking with Dave about why synchronization and replication are an important part of the bus.  I realized part of the disconnect we've been having derives from the differing “big problems” each of us find ourselves confronted with.

As infrastructure people one of our main goals is to get over our “information chaos” headaches…  These have become even worse as the requirements of audit and compliance have matured.  Storing information in one authoritative place (and one only) seems to be a way to get around these problems.  We can then retrieve the information through web service queries and drastically reduce complexity…

What does this worldview make of application developers who don't want to make their queries across the network?   Well, there must be something wrong with them…  They aren't hip to good computing practices…  Eventually they will understand the error of their ways and “come around”…

But the truth is that the world of query looks different from the point of view of an application developer. 

Let's suppose an application wants to know the name corresponding to an email address.  It can issue a query to a remote web service or LDAP directory and get an answer back immediately.  All is well and accords with our ideal view.

But the questions application developers want to answer aren't always of the simple “do a remote search in one place” variety.

Sometimes an application needs to do complex searches involving information “mastered” in multiple locations.   I'll make up a very simple “two location” example to demonstrate the issue:  

“What purchases of computers were made by employees who have been at the company for less than two years?”

Here we have to query “all the purchases of computers” from the purchasing system, and “all empolyees hired within the last two years” from the HR system, and find the intersection.

Although the intersection might only represent a few records,  performing this query remotely and bringing down each result set is very expensive.   No doubt many computers have been purchased in a large company, and a lot of people are likely to have been hired in the last two years.  If an application has to perform this type of  query with great efficiency and within a controlled response time,  the remote query approach of retrieving all the information from many systems and working out the intersection may be totally impractical.   

Compare this to what happens if all the information necessary to respond to a query is present locally in a single database.  I just do a “join” across the tables, and the SQL engine understands exactly how to optimize the query so the result involves little computing power and “even less time”.  Indexes are used and distributions of values well understood: many thousands of really smart people have been working on these optimizations in many companies for the last 40 years.

So, to summarize, distributed databases (or queries done through distributed services) are not appropriate for all purposes. Doing certain queries in a distributed fashion works, while in other cases it leads to unacceptable performance.

The result is that many application developers “don't want to go there” – at least some of the time.  Yet their applications must be part of the identity fabric.  That is why the identity metasystem has to include application databases populated through synchronization and business rules.

On another note, I recommend the interview with Dave Kearns on the importance of context to identity. 

Charles Fitzgerald doing “platformonics”

I just discovered that Charles Fitzgerald, General Manager of Platform Strategy at MS, has started a blog called Platformonics.  I know a lot of industry people will be interested – Charles has really been around the block at the highest level.  I think he learned more from “Hailstorm” than anyone else who I've spoken to.  Beyond that, he's a great business person, well-read and beautifully wry.  Here's a piece full of implications called There is no free lunch (especially in France):

The BBC reports the French security service has told French government officials not to use Blackberries because their data is stored in foreign countries and could be susceptible to prying eyes. Expect many more such awakenings going forward to the tradeoffs to putting data in the cloud.  Not just national security concerns, but trade secrets, privacy and compliance requirements will all require people to think more explicitly about the risks and tradeoffs of where you put your data and what can happen to it.  Today's all or nothing approach is a crummy way to do it. Three contenders for the most amazing part of this story:

  1. They're just realizing this now?  Did they just figure it out or did some incident precipitate this decision?  There is probably a pretty good spy novel in if you combine this with almost any headlines from France in recent years.
  2. French officials are “flouting the ban”.  I predict the upcoming ban on smoking in public places in France takes “flouting” to a whole new level.
  3. RIM insists the US National Security Agency can't read content on their service.  Disciples of Taleb might call that epistemological arrogance.

Oh yeah, I almost forgot.  Charles has been a great supporter of the Laws of Identity – ribbing me by somehow learning to recite the title with reverb.  He was also one of the first to see the potential of Information Cards.