Monthly Archives: February 2007

Bandit, Community, and Corporate Deployments

In my last post, I talk about three ways that the Bandit Project is contributing to emerging Internet identity space. In this post I want to expand on the third area of that post. This area will be an increased focus of the Bandit project this year. Since the Internet identity systems are happening, we are betting that the Bandit components will be strongly needed, and we expect them to be deployed in real world installations. And we want to accelerate that process.

So we are starting to visit deployment sites and validating these concepts, as well as our component designs and project communication. We’ve been learning a lot. What follows is an excerpt from a letter I sent to some enterprise sites to illustrate our reasoning. It was sent to some Novell customers, hence the Novell focus, but don’t take that too strongly either. Often Novell customers write custom code to integrate web applications, and we want to make the identity integration at those points as easy as possible. But we work with non-Novell customers, partners, and other vendors just as well. Bandit components do not require Novell products (though we do try to make them work well together). Here’s part of the letter:

Bandit is an open source project, sponsored by Novell, that takes an evolutionary approach to reducing the difficulties of developing, deploying and integrating identity services into enterprise environments. We currently focus on simple components that implement runtime authentication, authorization, and auditing services. Novell products, partner products, and custom applications that use these components can consume identity from any source, make flexible and powerful authorization policy decisions, and ensure that access is audited in a consistent manner.Open source projects such as Bandit give Novell a very effective way to collaborate with their customers. Developers at customer sites can have direct access to the project team and Novell engineers. They have full access to all aspects of the development process. Features and project road map are directly and transparently determined.Open source development has consistently done well in areas that require interoperability and implementation of standards. This seems like a perfect fit for identity services in most enterprise environments. Multiple identity systems and standards, mismatched products from a variety of vendors, and constantly changing company boundaries all conspire to make identity services difficult to deploy and maintain. Yet identity services are most critical to company information, processes, and compliance verification.Bandit is completely open source in code and development style. We implement standards and use existing APIs and frameworks when possible. We work with many other open source projects to integrate, reuse, and collaborate.

All this makes sense to me and the Bandit team, but we intend to validate and evolve this project vision with the community, customers and partners. Also, we intend to actively explain how and why we believe this project works. We would like enterprise developers to work with us. The project is still in early stages, but real value is there now. We want to provide open source code to access existing and future systems — yet early involvement also will give greater influence in project direction.

The Internet identity foundation is coming together quickly. Useful Bandit components are already available. Over the next year, the Bandit team will be focusing more on integrating our development with the community, customers and partners to validate and evolve the project vision.

It also sounds like great fun to me! I’m looking forward to it.

The Internet Identity Explosion and the Bandit Project

There has been a huge flurry of activity in the Internet identity space in recent months mostly around convergence, working code, and actual deployments.

Since I am an unashamed Bandit, I am sometimes asked “where does the Bandit project fit in all this?” I think that it fits in three ways:

First, Bandit supports the above mentioned projects and convergence points.

We participate in the community as much as we can, and we are one of the few projects I have seen that will actively contribute code to other projects. We NEED this stuff to work coherently and we work to accelerate convergence where possible.

In some ways the Bandit project is much like our close ally, the Higgins Project. Both projects write open source code that glues together existing and future systems. Neither project pushes a particular protocol family or identity system. Higgins provides a framework that supports a common interface to multiple identity systems and protocol families. Bandit needs such a framework, so we contribute to Higgins to help it get done faster. We work with Higgins on other shared components as well.

We are also excited to work with the new Pamela Project. It fills a very important need for consistent relying party code that is usable, robust, and handles evolutionary accounts from existing silos to the emerging identity systems. Relying parties need consistent user experience too.

Most projects that we work with are open source. I personally would want my identity information handled by open source software. I also think that open source development is particularly good at interoperable components of distributed systems — like identity systems.

.
Second, Bandit adds a layer of open source components for consistent authentication, authorization and audit capabilities.

You might say that accelerating convergence, contributing code to other projects, and some authentication code is necessary before we can build effective authorization and audit components. We need a cohesive, distributed identity system. But we also know that when we get such a system, some critical issues involving authentication, authorization, and audit will surface.

Bandit focuses on simple, reusable components for authentication, authorization, and audit. These capabilities are most recognized as needed in enterprise identity systems, but I think they will be needed in other places as well. The recent experiences of the Bandit team and others are confirming this. Once applications or services (web based or otherwise) start to actually be used by more than a few users and sources of identity, they immediately find they need a general, scalable solution for authorization and audit.

Authorization means determining whether a particular user can perform an operation. Most network services really support authorization based on something like a role. For example, a wiki may have a notion of an administrator, an editor, and a reader. The Bandit Role Engine will allow a sysadmin great power and flexibility in how to map security tokens, claims, and other information into the native roles of the system.

Auditing is needed to provide an record of who did what. In the case of most of the emerging Internet identity systems we are particularly interested in providing a record for the user of what a service has agreed to do for them. Think of it (in the insight of Bob Blakley) as the receipt from a Relying Party. Audit records are also needed (like a cash register receipt log) to help a service prove compliance with various accounting regulations.

Bandit is not limited to these components or use cases, but they illustrate the point. From the main project page:

Bandit is a set of loosely-coupled components that provide consistent identity services for Authentication, Authorization, and Auditing.

Third, the Bandit Project is a conduit between developers and those who make these systems work in real deployments.

The Bandit Project works with Novell product teams, other vendors, current and future customers to determine what still needs to be done to make these identity systems work in real deployments. This will be an increasing emphasis of the Bandit Project this year.

More on this third point in the next post.