Jeff Jaffe’s Blog

In my previous two major posts, I traced the role that Open Source now plays in innovation and in standards creation. I described how this is the ideal environment for creating innovative open standards for identity management. The Bandit project was established several months ago with this objective. In this post, I will describe some of the technical highlights of this project.

Representing digital identity

For identity management to be successful, we need a common vocabulary to talk about digital identities. How are they represented? What are their properties? What is a consistent method for identity management systems to interpret digital identities – and hence exchange information about them.

A project that intends to create a comprehensive way to think about this problem is the Higgins project. This project looks at numerous methods that are used to characterize digital identities today with the intent of integrating common identity capabilities. It is the first project to really think through the harmonization of digital identities in the corporate world with user-centric digital identities used by individuals and consumers on the Net.

Higgins is an existing open source project that now contains many portions. One of them (Identity Attribute Service, IdAS) is essentially a service provider interface for access to multiple identity repositories. There are a number of unique characteristics of this design, but the API and the registration system for plugins (called context providers) are Higgins code, hosted in the Higgins Eclipse project. The Bandit project is using the Higgins IdAS in a number of components. But Bandit is also providing implementations of context providers (for LDAP directories such as eDirectory and Active Directory) to Higgins.

The interaction between the Bandit and Higgins projects is a very good example of how open source projects accelerate innovation by encouraging collaboration. Higgins and Bandit actually started independently of each other, but both projects realized the value of working together in some aspects and are now accelerating each others development. It was noted in my last major post that, whereas proprietary approaches often create competing standards, in Open Source the standardization around the code that everyone can share encourages related projects to collaborate rather than compete.

Authentication

Authentication systems have been around for years, and there are several standards that support them. It is vital that, as new technologies are introduced, the innovations are rapidly incorporated in a standard way. An important example is the secure vault – increasingly popular for system and user credentials. Bandit is defining a Common Services Authentication Adaptor (CASA) to introduce a standard approach to this innovation.

More recently, CASA has moved beyond being a credential store. In now uses glue modules to support multiple authentication methods in client and server code.

Roles

One of the major concerns that I mentioned in my last post is to get consistency in representation of roles. Role-based access has become an innovative method to simplify the specification and management of identity management systems. But every company does it differently. The goal here is to provide an Open Source solution – to simplify for customers via standardization.

Ideally, we would standardize a single method to specific roles. Unfortunately, it is too late for that. Too many existing systems have gone out with their own unique method to specify roles. So what can we do about that?

Bandit’s approach is as follows. Bandit looks for what the similarities are in existing systems. For example, the very concept of the “role” implies that almost all systems have the concept of group membership in one form or another. So Bandit is creating a role calculation engine to make it easy to attach existing access control policies to organizational roles.

Audit, events, compliance

Identity management systems have evolved beyond being simple access control systems, to being systems for corporate compliance and governance [cf my blog post of May 30]. Each of these new innovative features are being introduced as we speak – and again we run the risk of incompatibility. So Bandit contains an Application Programming Interface (API) to receive audit records from Bandit’s open identity services. As a result we get a standard format for audit records. This standard format, of course, can also be used by other programs – outside of the Bandit framework.

Common Components

As mentioned in previous postings, standardization via documents and standards committees often lead to a situation where some things are open to interpretation which lead to incompatibility. With Open Source standards such as Bandit, the popularization of the GPL code leads to standardization. For example, with CASA, participants in authentication, whether they are servers, clients, devices, applications, or identity management systems, all have access to the same code. To participate in this framework, a system merely needs to include the common CASA code.

In my post on August 21, I argued that Open Source is the new innovation paradigm and that it is also effective for setting standards. Herein, I give a great example, the Bandit project, which is establishing an Open Identity Framework. I will describe the pressing need for an Open Identity Framework and describe the characteristics of Open Source that make it a great fit.

The problem

Identity services are very important to any form of computing. In a corporate environment, it is critical that resources be available only for authorized users. In an e-commerce environment, providers of services need to know who their users are so they can extend credit and accept payments. In a collaborative working environment, users want to know who other users are; alternatively there are times when user identities should be anonymized, hidden from others. Companies sharing information about their users need a common way to share (or federate) information about identities. Above all, privacy concerns are paramount when it comes to use or misuse of identity information.

Access control systems and identity management systems have been around for years: first to guard access to a single computer and application, later to manage directories across an enterprise, still later to federate this information across enterprises. As the complexity of tools around identity management has grown, as the usages of identity management have diversified, and as privacy concerns have mounted, this has all become rather complex. Standards exist to simplify some aspects, but standards development trails the speed at which the field moves.

Much of the complexity of interoperability is due to simplification of core identity systems! To simplify identity management, companies have simplified the user interface – allowing identity specification based on roles. But every vendor has introduced roles differently. As privacy issues and compliance constraints have grown, more powerful policy management facilities have been introduced. But every vendor has introduced policy differently. As identity management has become more integrated into applications, every vendor has integrated access control with workflow. But every vendor has caused this integration to be done differently.

So the rapid introduction of incompatible simplifiers – roles, policy, and workflow – has actually created more complexity. We need to innovate. We need to find a method to introduce these concepts in a way where the community can agree on their introduction.

The Open Source approach v. the standards approach

At Novell, this problem of incompatibility stared us in the face. It was not a new problem. The industry has had non-interoperable protocols for years. Prior to the open source days, these incompatibilites were most often worked out in standards organizations, after different firms created an early binding to their ideas. But standards organizations have many deficiencies:

• Speed. Many standards organizations are more focused on debating different approaches than sharing. Different innovators would come armed with reasons that their approach would win. Sometimes there were winners and losers and drawn out debates, rather than collaboration and rapid progress.

• A mixed result. One approach to deal with different algorithms was to compromise. On the face of it, this would seem to be a good idea. Take the best ideas from multiple innovators. Unfortunately, without a common design paradigm, this approach often results in a worse solution than any of the individual proposals.

• Proprietary implementations. Often a standard admits multiple potential interpretations. Two implementations of the same standard can be incompatible.

Not all standards organizations suffer from all of these problems. The Internet Engineering Task Force (IETF) is notable in that rough consensus and running code is often enough to select a standard. This addresses many of the cahllenges embodied in the first two issues above. Unfortunately, proprietary implementations still exist.

Each of these deficiencies are speed bumps on the way to rapid innovation. If there are long debates, poor compromises, or incompatibility, the technical community spends exceedingly long hours fixing the last generation, rather than creating the new generation.

Additionally, standards organizations often have a high bar for entry. An individual innovator might be effective in this community – but often, if (s)he cannot build on the works of others, (s)he is disadvantaged. For Open Source, any innovator can make his or her ideas and contributions available back to the community.

It is interesting to contrast in these two approaches where in the innovation process collaboration takes place, and where in the innovation process debate takes place. After all, even in the Open Source world, different innovators will have different ideas on how best to accomplish certain tasks, and there must be room for debate.

In the standards process, debate takes place without the sharing of code. Positions are hardened early. Collaboration is blocked. Sharing of intellectual property is limited.

In the Open Source process, debate takes place in the open. If someone brings a new approach which is gratuitously different from the previous ones, it will be frowned upon. However, if people legitimately have different approaches, and multiple approaches exist, different communities can innovate freely. Collaboration is encouraged through the sharing of intellectual property. If one team wants to ignore another, they are free to do so. If they see how to fit someone else’s idea into their framework, they are free to take the code and do so. In this way, the innovation process is not impeded early on. To be sure, if two companies want to commercialize different approaches, you can still get unfortunate incompatibility in the marketplace. But fortunately, this does not interfere with the speed and openness of innovation.

How is Bandit doing it? 12 companies in the press release

The ultimate test is whether thought leaders are willing to participate in the process. This was an item of anxiety for us in launching Bandit. After all, items such as workflow, policy, and roles are widely open for interpretation. Will different organizations, with different approaches, different roles in the industry, and different creative teams come together to use Open Source as the approach for resolution? We were gratified with the response.

In the launch press release for Bandit, we had Active Identity, the Eclipse Foundation, IBM, Liberty Alliance, Microsoft, Novacoast, Novell, Red Hat, Sun, Sxip Identity, Symantec, and Trusted Network Technologies commit to use this Open Source approach. Entities with different histories in terms of embrace of Open Source. The thought leaders of Identity Management in the industry. We are on a path to success.

To make this discussion complete, I will next discuss the contents of Bandit. That will be in the next post.