{"id":1215,"date":"2012-06-18T06:05:47","date_gmt":"2012-06-18T14:05:47","guid":{"rendered":"\/?p=1215"},"modified":"2012-06-18T23:30:39","modified_gmt":"2012-06-19T07:30:39","slug":"the-identity-ecosystem-identity-model","status":"publish","type":"post","link":"https:\/\/www.identityblog.com\/?p=1215","title":{"rendered":"Identity Management before the Cloud (Part 2)"},"content":{"rendered":"

The First Generation Identity Ecosystem Model<\/strong><\/p>\n

The biggest problem of the \u201cdomain based model of identity management\u201d<\/a> was that it assumed each domain was an independent entity whose administrators had complete control over the things that were within it \u2013 be they machines, applications or people.<\/p>\n

During the computational Iron Age – the earliest days of computing – this assumption worked.<\/p>\n

But\u00a0even before the emergence of the Internet we began to see\u00a0domains colliding within closed organizational boundaries – as discussed here<\/a>.\u00a0 The idea of organizations having an \u201cadministrative authority\u201d\u00a0revealed itself\u00a0to be\u00a0far 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.<\/p>\n

Many of us who\u00a0worked on\u00a0IT\u00a0architecture\u00a0were therefore already looking for ways to transcend the domain model even before the Internet began to flood the enterprise and wear away its firewalls.\u00a0Yet the Internet profoundly shook up our thinking. On the one hand organizations began to understand that it was now possible \u2013 and in fact mandatory \u2013 to interact with people as individuals and citizens and consumers. And\u00a0on the other\u00a0any organization that\u00a0rolled up its sleeves and\u00a0got to work on this soon saw\u00a0that\u00a0it needed a model where\u00a0it could \u201cplug in\u201d to systems run by\u00a0partners and suppliers\u00a0in seamless and flexible ways.<\/p>\n

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\u2019t viable to recode or \u201cchange out\u201d systems every time organizations were realigned or restructured.<\/p>\n

Technologists introduced\u00a0new 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\u00a0sends them\u00a0to\u00a0an\u00a0IdP which authenticates them and then returns identifying information to the service provider (an RP within the model).\u00a0 All the CRUD <\/a>is performed by the IdP which issues credentials that can be understood and trusted by RPs.\u00a0 It is a formal division of labor – even in scenarios where the same “Administrative Domain” runs both the IdP and the RP.<\/p>\n

\"\"<\/p>\n

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\u2019s 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\u2019s business (for example, the maintenance of login and password systems for retirees or consumers).<\/p>\n

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\u00a0excellent interoperable products from a variety of technology companies are\u00a0being deployed.\u00a0<\/p>\n

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.\u00a0 These difficulties grow geometrically\u00a0for organizations that want to establish relationships with a large number of other other organizaitons.\u00a0\u00a0Establishing configuration and achieving secure connectivity is hard enough, but keeping the resultant matrix of connections\u00a0reliable in an operational sense can be daunting and therefore seen as a real source of risk.\u00a0<\/p>\n

\"\"<\/p>\n

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\u2019t have accounts) with many different web entities. Most concluded that it would be a gamble to switch from registering and managing \u201ctheir own users\u201d to figuring out how to successfully reuse peoples\u2019 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\u2026<\/p>\n

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).\u00a0<\/p>\n

[Next in this series: Disruptive Forces: The Economy and the Cloud]<\/em><\/p>\n","protected":false},"excerpt":{"rendered":"

Most organizations have found identity federation hard to do.<\/p>\n","protected":false},"author":68,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":[],"categories":[2],"tags":[],"_links":{"self":[{"href":"https:\/\/www.identityblog.com\/index.php?rest_route=\/wp\/v2\/posts\/1215"}],"collection":[{"href":"https:\/\/www.identityblog.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.identityblog.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.identityblog.com\/index.php?rest_route=\/wp\/v2\/users\/68"}],"replies":[{"embeddable":true,"href":"https:\/\/www.identityblog.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=1215"}],"version-history":[{"count":0,"href":"https:\/\/www.identityblog.com\/index.php?rest_route=\/wp\/v2\/posts\/1215\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.identityblog.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=1215"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.identityblog.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=1215"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.identityblog.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=1215"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}