Plausible Deniability

Before his turn in the cinematic tour de force Ferris Bueller’s Day Off, Matthew Broderick starred in a movie called War Games that was possibly my introduction to the world of identity management. The details are hazy, but I recall that Broderick’s character hacked onto the US national security network and inadvertently set the world on the path to nuclear meltdown and mutually assured destruction. The conceit of the film was essentially one of identity fraud - the system assumed that a user was authorized and entitled to launch ICBMs based on his presentation of a (stunningly simple) set of credentials - a little more serious than fooling a system into thinking you are both an administrator and equity trader. Obviously, security has taken strides since the early 1980s, but taking the squishy, human idea of identity into the world of systems is still a work in progress.

Of course, a user always has to prove they are who they say they are within well-defined parameters, but who they are can also be driven by the context, and what level of access is required for their function. The context can change by application - examples abound in verticals like healthcare and financial services - and level of access is not always consistent with function - it may also relate to organizational seniority or external considerations like regulatory compliance. The scope of the challenge of managing identities with multiple facets related to how to an organization functions has given wings to any number of marketing terms and technology descriptions: composite identities, converged identities, identity cubes, role management (and the list goes on). All this implies that there are bits of identity sprinkled across an enterprise infrastructure that must be consolidated, reconciled and aggregated. And, we are only at the tip of the iceberg in terms of communicating the semantics of these identities across domains - although as Chris Swan notes the mechanism for cross-domain authentication exists. The realization that user identities are some way incomplete or too fragmented is driven by the need for visibility and control mandated by regulatory compliance but also presents an opportunity to rethink identity management from the ground up.

It may misleading to define, however, to characterize an identity as whole or partial. A user’s identity should be the sum of the parts, otherwise the concept of identity doesn’t have any meaning - rather it’s a system-level association of a directory profile with a set of entitlements with no organizational context. But having a partial identity doesn’t imply that it’s inherently deficient. There is a subset of user-system scenarios where a system has to know everything about the user and a subset of of users that must be subject to constant control. For the most part, an identity management system is dealing with relatively benign user-system access patterns.

Instead, a more appropriate metaphor might be ‘heavy’ and ‘light’ identities, that populate a continuum defined both by organizational hierarchies and level of risk associated with any particular action. As we’ve noted in our Market Insight Service, heavy identities are defined by nature of the privileges and permissions associated and the role of the user but also the risk that they represent if not protected. As the degree of access requires more information on the user – not simply ‘are you a company employee’ or ‘can you satisfy a challenge for your Active Directory credentials’ – the identity becomes heavier. In order to scale systematically and limit management, identity management must implement controls in tandem with the ‘heaviness’ of the identity.

This all assumes a modular approach that involves some form of communication of data from a dedicated application repository to a centralized policy - something approximating a directories 2.0 approach - rather than conversion of data into a single, monolithic identity store and some form of policy engine with rules on when to invoke ‘heavy’ identity management processes. An open, modular approach may seem like a bridge too far until you consider the implications: rather than forcing all identity data through a bottleneck, it can remain distributed in order enable flexibility and access and policy rules can be defined hierarchically. For instance, where an individual identity has access to credit card data as part of their application entitlements, the local policy must be marked and subordinated to a centralized policy engine before it can be approved. Other elements of the policy related to authentication and access control can remain localized.

This approach also allows for the persistence of disparate identity stores, but a greater degree of communication between them based on cross- and intra-domain federation models, providing far more flexibility in managing fluid identities, and reducing the amount of data (and by extension management complexity) that has to reside in one single, consolidated identity store.

There are obviously some interesting pieces of the puzzle that are emerging to facilitate this type of ‘SOA for identity’. One element, of course, is standardized protocols to communicate data and higher-level concepts such as attributes and entitlements between identity stores (XACML and SAML spring to mind). Another is new ways of organizing the relationships within directories such as the Higgins Data Model or providing an overlay onto existing identity management systems in the form of role management (although this is more a vendor-specific approach from companies such as Aveksa, Courion, Eurekify and Sun through its acquisition of Vaau). Role management allows for a more granular definition of the spectrum between heavy and light, and identify what specific elements move the dial.

This concept of heavy vs light links nicely with what I believe could be an interesting model for security – creating a flexible balance between availability of resources and fine-grained policy enforcement by enforcing granular access controls based on the escalation of privilege levels. At each step, the identity gets heavier, and more security controls can get invoked. Most human organizations are organized hierarchically – it makes sense to structure identity management in the same way. This model implies extending directories in a manageable, systematic fashion and much more transparent policy enforcement between applications and identity management data. Agents probably won’t scale, and the model can’t involve vendor-specific methods of speaking to application components. metadata policy engine. None of this is trivial, but the fact that identity management license price points are heading in one direction suggests that it’s time to start seeing how the pieces of the puzzle fit together.