Starting the Revolution: Implementing an Identity Management Architecture

Introduction

Identity management (IdM) is often seen as a purely technical solution to a problem that exists in an enterprise. As a result, many enterprises tend to design and adopt IdM solutions that result in an almost single-minded focus on the technical design and implementation. This technical focus may result in the IdM solution ignoring the organizational ecosystem that surrounds it. The outcome often appears to end with an implemented solution that is not what the enterprise really needs. It only takes a few minutes of searching in some of the professional forums¹ to see that many IdM implementations fail to achieve their objectives.

But, an Enterprise Architect who is attempting an IdM design finds very quickly that the current understanding of an IdM enterprise framework really depends more upon a particular vendor’s implementation than on a clearly defined model. Most major vendors offer complete IdM systems. But they often offer some components of those IdM systems as separate, stand-alone systems that can be installed and later linked together into a system that can provide some IdM services. Strictly speaking, this could be potentially recognized as an implementation of a framework that allows interoperability between the components (Gamma, Helm, Johnson, & Vlissides, 2000) but it does not define a formal model of an enterprise identity management system.

There are four basic models of IdM systems: Enterprise, Distributed, Internet and Federation (White, 2009). There appears to be some disagreement in the literature over the description of these models and their characteristics (White, 2009, pp. 35-40). The literature does not appear to agree upon a formal model, framework or architecture for an enterprise IdM model. This is possibly due to the fact that the literature tends to concentrate on each technical component to the virtual exclusion of all other components, except where they are either a pre-requisite or a dependency. The effect is that each component is viewed within a very restricted and narrow context and without the holistic view required for an enterprise system. There is also a considerable focus on the description of Internet and Federation modules in the literature (Cantor & Erdos, 2002; Cantor, Hodges, Kemp, & Thompson, 2003; Jones & Cameron, 2005; Josang & Pope, 2005; Meinecke, Nussbaumer, & Gaedke, 2005; Zhu, 2007).

But this lack of a formally described enterprise or base level framework leaves most enterprises without a foundation on which to base an adequate assessment of their needs or of any proposed system. It also means that an enterprise is left with no real guide to the design of an IdM system that will meet their requirements. It seems that the current view of an Enterprise model of an identity management system depends more upon an individual vendor’s implementation than on a defined model.

This problem of a clearly defined model for the design of IdM solutions leaves both practitioners and researchers without a clear and consistent foundation on which to base a design.

It is further complicated by the fact that IdM is an area that is not clearly defined either in industry or in the literature. Many people claim to know what it means, but the definitions they use are often very different and address different aspects of the IdM ecosystem. The situation with Government IdM projects in Australia can be viewed as an example of problems that arise when there is not a clear definition of aims or ecosystem at the start of a project (White, 2008).

Is it any wonder that major projects continue to fail when we, as an industry, cannot provide practitioners with a basic agreed model to build on?