{"id":1209,"date":"2012-06-04T10:51:59","date_gmt":"2012-06-04T18:51:59","guid":{"rendered":"\/?p=1209"},"modified":"2012-11-08T09:39:34","modified_gmt":"2012-11-08T09:39:34","slug":"identity-management-before-the-cloud-part-one","status":"publish","type":"post","link":"https:\/\/www.identityblog.com\/?p=1209","title":{"rendered":"Identity management before the cloud (part one)"},"content":{"rendered":"

Since identity is a fundamental requirement of computing infrastructure, organizations have been involved in digital identity management for decades.\u00a0 Over the years, three models have emerged and co-existed.\u00a0 Of course\u00a0I'm tempted to\u00a0skip the history and\u00a0jump headfirst into what's new\u00a0and fresh\u00a0today.\u00a0\u00a0But I think it is important\u00a0to\u00a0begin by reviewing\u00a0the earlier models\u00a0so we can\u00a0get crisp about\u00a0how the IdMaaS model differs from what has gone before. (Some day people who want to skip the\u00a0previous models\u00a0will be able to click here<\/span>.)<\/p>\n

Firewall Era Identity Model<\/strong><\/p>\n

\"DomainEnterprise identity technology evolved incrementally from mainframe days using the concept of administrative and security \u201cdomains\u201d: collections of resources tightly integrated under a single, closed organizational administration.<\/p>\n

To control access to networks, computers, applications and information stores, it was necessary to identify them and recognize their legitimate users \u2013 whether people or software services. This required registration systems \u2013 often called directories \u2013 through which human and non-human identity records could be created, retrieved, updated and deleted (CRUD). In the domain paradigm identity management was thought to be the\u00a0CRUD and little more.<\/p>\n

While closed administrative domains were simple in theory, business requirements drove enterprises to adopt an assortment of unrelated internal systems and applications. Most came with their own independent user directories. Enterprises ended up with hundreds of different systems that had to be administered independently and would soon diverge.<\/p>\n

With the advent of network PCs, we began to see\u00a0Network Operating System\u00a0<\/a>domains that were collections of PC's working in conjunction with servers.\u00a0 Banyan<\/a>‘s StreetTalk and\u00a0Novell's\u00a0Netware<\/a>\u00a0were both\u00a0gamechanging\u00a0products\u00a0that introduced\u00a0LAN directory coupled with identity management and authentication capabilities, but over time Active Directory\u00a0<\/a>achieved predominance\u00a0as the administrative and security domain for PC users and applications.\u00a0These products\u00a0greatly simplified management of personal computers but the plethora of specialized business systems remained.\u00a0 In fact some enterprises ended up with multiple Active Directories.<\/p>\n

A category of Identity Management integration products arose as a response to these problems: a dizzying array of often brittle point products and tools that could only be deployed at high cost by skilled specialists. They generally had to be customized to the point of being one-off solutions that\u00a0paradoxically made the legacy even harder for customers to unravel.<\/p>\n

In retrospect the\u00a0most\u00a0striking characteristic of the domain based model is that\u00a0each domain spoke with absolute authority.\u00a0 It named things and asserted their attributes.\u00a0\u00a0The machines, services and administrators that were part of the domain took its assertions as being unquestionable.\u00a0 Trust for the domain was a condition of membership.\u00a0 There was no need for the evaluation of assertions since they came from the domain and the domain was right by definition.<\/p>\n

Another characteristic was that\u00a0each domain created identifiers\u00a0within a namespace it controlled and they\u00a0 could be used to access the information about domain members and components by\u00a0any entity\u00a0the domain authorized.\u00a0\u00a0Systems typically employed a single namespace, and services used the same identifiers\u00a0that were associated with domain components\u00a0and users at authentication time.<\/p>\n

In other words,\u00a0until domains began to collide, it was a pretty simple world.\u00a0\u00a0Conversely, in todays interconnected and permeable world, most of the assumptions underlying the domain apply with growing caveats.\u00a0\u00a0\u00a0<\/p>\n

Internet-facing Identity Model<\/strong><\/p>\n

The explosion of the Internet surrounded the closed enterprise security domains with outward-facing systems aimed at customers and suppliers.<\/p>\n

Once Web usage went beyond public applications like PR and advertising, organizations discovered that to enhance relationships with individual customers \u2013 and ultimately do e-Business – they needed ways to register them over the web.\u00a0\u00a0\u00a0Customers and suppliers\u00a0were seen as a different category of domain object, but the systems built for them still followed the domain model.\u00a0 Anything the domain said about its customer or supplier was taken to be true by all the applications in it.<\/p>\n

Consumer and supply chain identity management was most often customized on top of existing business databases that were completely independent from the directories of employees maintained inside the corporate firewall.\u00a0<\/p>\n

This created problems in linking employees with customers. In the wake of mergers and acquisitions, companies struggled to deliver a unified experience to customers across multiple business units with diverse origins, and competition drove them to seek more unified identity and resource management services.<\/p>\n

The Identity Management market thus expanded to include products that performed single sign-on and\u00a0unified access control across a set of colliding domains, accompanied by large expenditures on hand-crafted integration projects.<\/p>\n

Next:\u00a0 Identity Management before the cloud – the Identity Ecosystem Model<\/p>\n","protected":false},"excerpt":{"rendered":"

In retrospect the most striking characteristic of the domain based model is that the domain spoke with absolute authority.<\/p>\n","protected":false},"author":68,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":[],"categories":[2,86,87],"tags":[],"_links":{"self":[{"href":"https:\/\/www.identityblog.com\/index.php?rest_route=\/wp\/v2\/posts\/1209"}],"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=1209"}],"version-history":[{"count":1,"href":"https:\/\/www.identityblog.com\/index.php?rest_route=\/wp\/v2\/posts\/1209\/revisions"}],"predecessor-version":[{"id":1326,"href":"https:\/\/www.identityblog.com\/index.php?rest_route=\/wp\/v2\/posts\/1209\/revisions\/1326"}],"wp:attachment":[{"href":"https:\/\/www.identityblog.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=1209"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.identityblog.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=1209"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.identityblog.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=1209"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}