Open Identity Services – the 5th generation of Identity Management
May 21st, 2007 by Jeff Jaffe
In June of 2006, Novell with several partners launched the Bandit project, to provide Open Identity Services. In September, I posted an outline of our objectives. As the project has evolved and new requirements have arisen, the objectives have become clearer and broader. Earlier this month, at the 1st European Identity Conference in Munich, I had an opportunity to reformulate and clarify these goals.
The history of Identity Management Systems
In our work on identity services, we are focused on the fifth generation of identity management. Previous generations:
-
Simple access control to applications.
-
More sophisticated technologies for access control; including multi-factor authentication, biometrics, directories, and metadirectories with synchronization.
-
Development of technology that provides massive simplification for user provisioning. Examples include roles based access, policy management, integration into application workflow, and Application Programming Interfaces. This is the current generation of identity management that is prevalent in the field.
-
Integration between different identity management functions. Specifically, this includes support for federated identities (Liberty Alliance) for enterprises, as well as web access management (for example what we provide with our Access Manager product. A second example is Novell’s Identity Manager 3.5, which integrates identity management, access management, and security information event management to help with compliance management. This is the current generation being shipped and will be the prevalent generation in the field over the next several years.
The evolution to Identity Management Services
Now, the paradigm of identity management should change from a focus on authentication to a focus on a multiple services provided by identity management systems and consumed by applications in different ways – through a consistent interface.
Historically, identity management started by controlling access to resources. With the third generation of identity management, there was a subtle shift. Rather than focusing on the protection of resources as the major area of investment, the attention shifted to the application and to management. Consequentially, instead of adding additional authentication technology, the focus was on the ease of use and integration of the identity management system. The enhancements were role management and policy management (to simplify the management aspect of identity) and workflow and application programming interfaces (to make it more natural for the application).
To be sure, the identity management still related principally to authentication and authorization. The change related to which problem we were solving within authentication and authorization. We were recognizing a growing set of consumers of the authentication service.
With the fourth generation, however, we started to recognize that identity management systems were the best repository of information about users. And there is much more usage for user information than merely managing their identities. So with the fourth generation, with the growth of compliance concerns, identity management systems began to provide the base support for compliance systems.
The application to compliance systems is immediate and timely in an era of Sarbanne-Oxley and Basel II. But once you recognize the relevance of identity to compliance, you also recognize the power of identity management systems to deliver much more. While compliance systems consume identity for the very specific purpose of regulatory compliance, other applications will want to consume identity for more general purposes. What Web based application does not want to know more about its users? This would give the application the ability to personalize its services to the user.
Identity as a service
So suddenly, identity management is flipped over again in terms of usage. In the past, we managed a user’s identity in a bounded set of access control usages. There was usually a well defined, singular place where the system had the user’s identity defined. In the new model, there will be multiple consumers of identity. Each consumer is a different application with different personalization needs. Correspondingly, the user’s identity might readily be defined in numerous inconsistent fashions; different databases defined by different sources. Some of these sources might be the company’s definition of how a user accesses resources in the company. But other sources of identity might be a user’s self-definition of his/her identity to a Web based service or an application that is trying to provide personalized service.
The change is stark. Rather than a monolithic corporate identity management system, we have a lightweight collection of capabilities: identity sources and attributes that must be brought together, provided in a coherent fashion, and consumed by multiple users of this information. The relevant paradigm then is for an identity management system to be a service. It has means to collect data from disparate sources. It has means to harmonize that data. It develops the right abstractions to make that available to consumers.
Open source as a methodology to develop the idea of identity as a service
In an earlier posting, I already described how Open Source was the perfect methodology to introduce these services. I won’t repeat it here, but that was the next module of my conference presentation.
The Bandit project, revisited
When I previously described our objectives for the Bandit project, I focused on the key functional areas that we were working on (e.g. CASA, roles, Audit and compliance). As mentioned above, the goals and focus have evolved. While these functions continue to be important, we are equally focused on structure. So the Identity Interface Layer is primary.
In this layer, we provide architectural support to accept multiple simultaneous authoritative data sources. We support composable identity tokens to allow advanced features for applications that want to consume identity information. We provide architectural support to deal with enterprise specification of identity data and user specification; corporate notions of identity and Web access. We provide a clean abstract view of an identity store to allow multiple usages of identity. And we ensure that there is a clean context for reporting, auditing, and compliance.
The next steps
We continue to learn and evolve this project. We are far from done. As we add cleanliness and abstraction, we need to focus on more varied means of consumption of identity.
Personalization is a case in point. We have barely scratched the surface in ensuring that we have the flexibility in dealing with user attributes that applications will want. How will we address this? Well, this is an open source project. We hope that colleagues will jump in, and help us out!