Identity Management before the Cloud (Part 2)

The First Generation Identity Ecosystem Model

The biggest problem of the “domain based model of identity management” was that it assumed each domain was an independent entity whose administrators had complete control over the things that were within it – be they machines, applications or people.

During the computational Iron Age – the earliest days of computing – this assumption worked.

But even before the emergence of the Internet we began to see domains colliding within closed organizational boundaries – as discussed here.  The idea of organizations having an “administrative authority” revealed itself to be far more complicated than anyone initially thought, since enterprises were evolving into multi-centered things with autonomous business units experiencing bottoms-up innovation. The old-fashioned bureaucratic models, probably always somewhat fictional, slowly crumbled.

Many of us who worked on IT architecture were therefore already looking for ways to transcend the domain model even before the Internet began to flood the enterprise and wear away its firewalls. Yet the Internet profoundly shook up our thinking. On the one hand organizations began to understand that it was now possible – and in fact mandatory – to interact with people as individuals and citizens and consumers. And on the other any organization that rolled up its sleeves and got to work on this soon saw that it needed a model where it could “plug in” to systems run by partners and suppliers in seamless and flexible ways.

With increasing experience enterprise and Internet architects concluded that standardization of identity architecture and components was the only way to achieve the flexibility essential for business agility, whether inside or outside the firewall. It simply wasn’t viable to recode or “change out” systems every time organizations were realigned or restructured.

Technologists introduced new protocols like SAML that implemented a clear separation of standardized identity provider (IdP) and relying party (RP) roles so components would no longer be hard-wired together. In this model, when users want a service the service provider sends them to an IdP which authenticates them and then returns identifying information to the service provider (an RP within the model).  All the CRUD is performed by the IdP which issues credentials that can be understood and trusted by RPs.  It is a formal division of labor – even in scenarios where the same “Administrative Domain” runs both the IdP and the RP.

The increasing need for inter-corporate communications, data-sharing and transactions led these credentials to become increasingly claims-based, which is to say the hard dependencies on internal identifiers and proprietary sauce that only made sense inside one party’s firewall gave way to statements that could be understood by unrelated systems. This provided the possibility of making assertions about users that could be understood in spite of crossing enterprise boundaries. It also allowed strategists to contemplate outsourcing identity roles that are not core to a company’s business (for example, the maintenance of login and password systems for retirees or consumers).

Many of the largest companies have successfully set up relations with their most important partners based on this model. Others have wisely used it to restructure their internal systems to increase their flexibility in the future. The model has represented a HUGE step forward and a number of excellent interoperable products from a variety of technology companies are being deployed. 

Yet in practice, most organizations have found federation hard to do. New technology and ways of doing things had to be mastered, and there was uncertainty about liability issues and legal implications.  These difficulties grow geometrically for organizations that want to establish relationships with a large number of other other organizaitons.  Establishing configuration and achieving secure connectivity is hard enough, but keeping the resultant matrix of connections reliable in an operational sense can be daunting and therefore seen as a real source of risk. 

When it came to using the model for internet facing consumer registration, service providers observed that individual consumers use many different services and have accounts (or don’t have accounts) with many different web entities. Most concluded that it would be a gamble to switch from registering and managing “their own users” to figuring out how to successfully reuse peoples’ diverse existing identities. Would they confuse their users and lose their customers? Could identity providers be trusted as reliable? Was there a danger of losing their customer base? Few wanted to find out…

As a result, while standardized architecture makes identity management systems much more pluggable and flexible, the emergence of an ecosystem of parties dedicated to specialized roles has been slow. The one notable entity that has gained some momentum is Facebook, although it has not so much replaced internet-facing registration systems as supplemented them with additional information (claims). 

[Next in this series: Disruptive Forces: The Economy and the Cloud]