First Open Source Reference Implementation of IGF 1.0

Over the past few months, a good deal of progress has been made around IGF and the open source implementation around it. In particular, last fall, Liberty Alliance ratified the IGF 1.0 specification as final. In mid January we published ArisID 1.1, the first open source implementation of IGF 1.0. Finally in late January, we checked in the first implementation of an open source provider based on OpenDS 2.2 (more on that below).

ArisID is an API for accessing and managing personal or identity related information using CARML as an XML data model. In addition to being useful from a privacy perspective, CARML enables important new developer features:

• The ability to automatically generate a data model in the form of Java beans.
• The ability to use sophisticated data providers that can connect applications to personal information sources using multiple protocols and virtualization.

If the principles of using an XML data model sounds familiar, it should. ArisID follows very similar architecture to Java Persistence Architecture. The key difference is that use of the CARML data model does not assume the pre-existance of a particular database or LDAP schema. Instead, a developer is able to create an application specific data model and write code as if the data model were a straight forward database. Then, at runtime, the provider layers of the API can be configured to connect to many different types of data repositories and network configurations including multiple directories or databases. With little effort, developers are able to create sophisticated applications that have much greater deployment flexibility in the types of data sources and repositories they can support, including remote and third-party sources.

Starting with the Oracle Fusion Middleware 11gR1(PS2) release, Oracle began to integrating this technology into its own products, setting the stage for a new level of support for open protocols and scalable enterprise deployment scenarios. For more information on how Oracle is using IGF and ArisID in 11gR1, check out the whitepaper, "Oracle Identity Management 11gR1".

As mentioned earlier, ArisID depends on "provider" modules to do the work of implementing data model requirements as expressed in application specific CARML declarations. At present there are now 2 implementations available:

• The Oracle OVD Provider for ArisID "Preview" is the first provider to support the ArisID 1.0 API. A developer preview is available here. Expect an update in the next quarter regarding ArisID 1.1.
  
• A brand new OpenDS 2.2 provider for ArisID is now available in the openLiberty sourceforge project repository. The new OpenDS provider allows developers to use OpenDS instead of OVD as a repository for applications using ArisID 1.1. The OpenDS Provider for ArisiD the first fully open source ArisID Provider implementation. For more information consult the readme file contained in the OpenDS Provider for ArisID distribution zip.

Project Aristotle is now moving forward with efforts to support integration into popular IDEs. As always, new contributors are always welcome, please see the OpenLiberty.org web site for more information. Also, feel free to subscribe to the igf-dev mailing list.

Finally, thanks to the OpenDS team (Ludovic, Bo, Matthew) for their assistance in helping to get the first open source implementation of a provider for ArisID done. In some respects, the Oracle/Sun merger delayed a lot of this work, but now that it is done, we can get back to work and contribute more to our respective projects. As Nishant Kaushik says, Sun + Oracle = Exciting Days Ahead! By the way, click here for webcasts about Fusion Middleware and in particular Identity Management.

Aristotle Project Wins Award

I am happy to announce that Project Aristotle won an award for "Best new or improved standard" at the European Identity Conference. The win is shared with the Open Authentication (OAuth) and the Information Card Foundation (ICF).

The European Identity Award for the category “Best new or improved standard” went to the Aristotle Project for ArisID, an important enhancement of IGF (Identity Governance Frameworks) and CARML, which enhances user-friendliness of these important standards for IAM and GRC. This particular innovation had been promoted and supported by Oracle. The standardization initiative OAuth (Open Authentication) receives an award for their streamlined approach for authentication standardization, which finds a lot of market interest. The last award in this category goes to the Information Card Foundation (ICF) for standardizing the important approach of Information Cards for future identity management.

Congrats to the contributors of openLiberty, the members of Liberty Alliance TEG, as well as my colleagues at Oracle, who all contributed to the effort. Congratulations to OAuth and ICF as the co-winners!

A special thanks to Kuppinger Cole for organizing the event and for taking the time to recognize the efforts of all the award winners and of standards development in general.

Big Changes!

Yesterday, my plan was to write a post announcing some changes at Project Liberty. I was distracted by the announcement that Oracle has entered into an agreement to acquire Sun Microsystems! Some other interesting coverage can be found here.

Now, the other big news!

The Liberty Alliance Project announced formation of a new organization known as the Kantara Initiative. Kantara is an organization with a much more accessible approach to its membership. It carries an Intellectual Property structure that is much more flexible and should allow for a greater ability to bridge between industry communities working on identity services. Brett McDowell, Executive Director of Liberty Alliance Project, gives an overview of the Kantara Initiative here:


One of the first big differences between Project Liberty and Kantara is that Kantara will be not be setting standards. Instead work groups will define recommendations to share with other standards setting organizations (SSOs). For example, the work on IGF AAPML, and various protocol profiles for IGF will likely each be referred to the SSO organization responsible for the parent specification.

For those following IGF and Project Aristotle, the work continues under the Kantara Initiative. One of the cool new features of the Kantara Initiative is the ability to support multiple open source projects with different licenses. This means it will be a lot easier to support a more diverse open source community. As an example, for Project Aristotle, it will make it a lot easier to work with the Higgins community now that we have a way to bridge between EPL and Apache licensing.

It seems that the themes of bridging and harmonization are in the air!

Defining Identity Modality

During my last webcast about Project Aristotle at OpenLiberty Project, I introduced a new concept called Identity Modality. The idea occurred to me as I was trying to describe the different types of identity exchange protocols and methodologies and how they impact developers.

I noticed there are several different ways and modes in which information is exchanged. There are times when the user is present (online) or is absent (offline), there are times when the transfer occurs through a backend system (such as with a database), and times when it occurs directly via the user. Finally, there are simple transactions (atomic) and then there are multi-step or workflow like transactions.

If you take these 3 different dimensions and place them on a 3-dimensional axis and plot popular means of exchanging identity information (based on typical usage), there are some interesting observations that can be made.


What struck me is how the notion of a front-end or browser-based protocols create a 3rd dimension of information exchange. The diagram also shows why SQL based systems are so ubiquitous - because it fully encompasses user-online/offline, atomic vs. workflow based transactions. Likewise LDAP, covers a smaller area, because it was intended as a lightweight, atomic (single-operation at a time) protocol. Where SQL fully exists in 2-dimensions, LDAP exists only in the atomic space handling both user online and offline scenarios.

Considering the challenges of developers writing applications and the objectives of Project Aristotle, the chart suggests why applications dealing with multiple modes of identity communication face a huge challenge. It becomes one the reasons why most applications end up with their own identity "silos" -- it's much easier to ignore systems outside the application.

One of the objectives behind the architecture of ArisID is to be able to handle all of these modalities through a single API. A loosely-coupled architecture means Identity modality does not have to be restricted to a specific hard-coded set of choices, but rather be configuration-based leveraging policy and environmental requirements.

ArisID Webcast Presentation and Demo Video

Thanks to all who attended the webcast on ArisID this morning! It’s always great to talk about this stuff and share ideas!

A copy of the presentation can be obtained here.

Also, as promised, here is a video of the Sonic Records ArisID demonstration. You can view it online here. Or, you can download the full-size video here (24MB).

Phil

IGF Demonstration at Catalyst

Burton Group's Catalyst Conference is coming up.

If you are coming to Catalyst, remember to stop by the Oracle hospitality suite on Wednesday and look for the OpenLiberty IGF demonstration. I'm excited to say that we are getting to the point where we can show how IGF will work in practice. I'll be there talking about the open source openLiberty IGF project and demoing how the IGF Attribute Service API works.

For those who have been following the Identity Bus discussion, you should also check out the demo. The Attribute Service API definitely shows off a lot of the desired requirements that the bloggers have been talking about.

See you there!

IGF Attribute Services API Demo

I've been meaning to create a demo showing what it might be like for a developer to write applications that access identity information using the new CARML-enabled Attribute Services API. Accordingly I've put together this brief 10 minute video that demos how easy it is to write a JSP script to access identity information through a declarative API without having to worry about protocols, vendors, or deployment environments - the Identity Bus/Metaverse/Network just deals with the application's requirements based on configuration and policy and the application benefits!

This video just shows the developer's experience and why I think developers might start to get excited. Yes, the API is privacy enhancing and all that stuff, but the reality is, any new API has to be easy, powerful, and open (as in Apache 2 License in this case) or developers just aren't going to care. Jeff, I hope this answers some of your important concerns!

The video does not cover how the API does its work, nor how is the deployment managed and configured. However, if you are planning on attending the Burton Group Catalyst Conference, please be sure to stop by the booth and I'll give you a walk thru! I'll try and post more video's of IGF in action as time permits!

I hope this video shows at least an initial concept that represents the kind of vision that Kim Cameron, Dale Olds, Jackson Shaw, Dave Kearns and many others have been talking about. I don't think we are there yet...for that, we're gonna need your input! Check out the openLiberty project today!

[Note: Oops!! I just saw the rendering that YouTube did of my video. With the downscaling the screen shots became incredibly blurry. I'm going to play around and see if I can post this video in a way that is clearer.]

Standards and Implementations

Kim Cameron posted a response today to my post yesterday about requirements for his next generation Meta-directory and how IGF aims to do just that. It seems Kim and I are in total agreement on these points and developer appeal is definitely key. I do want to clarify one paragraph from his response:

I haven’t seen CARML - perhaps it is still a private proposal? [UPDATE: I’ve been advised that CARML and the IGF Attribute Servces API are the same thing.] I think having a richer common representation for people will be the most important ingredient for success. I’m a little bit skeptical about confining developers to a single API - is this likely to fly in a world where people want to innovate? But details aside, it sounds like CARML will be a helpful input to an important industry discussion. Above all, this needs to be a wide-ranging and inclusive discussion, where we take lots of input. To get “as many applications as possible” involved we need to win the participation and support of application developers - this is not just an “infrastructure’ problem.

IGF is a collection of specifications (e.g. CARML, AAPML) that Oracle and others announced in November of 2006. With the positive response and encouragement from other vendors we quickly took the initial proposal for IGF to the Liberty Alliance on its way to making IGF an important identity information standard.

The AttributeServices API I spoke of is an Apache 2.0 License open source project under openLiberty.org that demonstrates just one possible implementation of the use of the IGF specifications. In other words, I totally agree with Kim on his skepticism about one API - the last thing we want to do is confine developers to a single API implementation. This was one reason why we went to the Apache License. We want to make it easy for other developers to take what we've done and port and adapt the implementation for their own purpose. From my perspective, the key is that all APIs should share implementation of IGF as a future standard.

To expand on Kim's point there are many communities that need to buy in: Developers, Privacy Officers, Deployment Managers, Infrastructure Managers for a start. But it goes without saying that if developers don't use it, none of this matters. Developers won't do this simply because the other parties (like infrastructure managers) want it. The key benefit I see for developers is the ability to write applications without having to worry about issues of deployment or issues surrounding protocol implementation through powerful development tooling.

Kim is correct about needing a wide-ranging inclusive discussion. We're doing that by developing the standard inside Liberty Alliance and by simultaneously developing the first reference implementation under openLiberty.org. I know there may be issues, particularly for small vendors to join the Liberty Alliance, but feel free to check out the mailing lists, and by all means, join up with OpenLiberty, which in contrast has wide open membership.

Kim Cameron On The New Generation of Metadirectory

As you may know, there has been an ongoing discussion on what does the next generation of meta-directory look like. Kim Cameron's latest post elaborates on what he thinks is needed for the next generation of "metadirectory".

• By “next generation application” I mean applications based on web service protocols. Our directories need to integrate completely into the web services fabric, and application developers must to be able to interact with them without knowing LDAP.
• Developers and users need places they can go to query for “core attributes”. They must be able to use those attributes to “locate” object metadata. Having done so, applications need to be able to understand what the known information content of the object is, and how they can reach it.
• Applications need to be able to register the information fields they can serve up.

These are actually some of the key reasons I have been advocating for a new approach to developing identity services APIs for developers. We are actually very close in our thinking. Here are my thoughts:

• There should be a new generation of APIs that de-couple developers from dependence on particular vendor implementations, protocols, and potentially even data schemas when it comes to accessing identity information. Applications should be able to define their requirements for data and simply let the infrastructure deal with how to deliver it.
• Instead of thinking of core attributes as those attributes that are used in common (e.g. such as surname is likely the same everywhere). I would like to propose we alter the definition slightly in terms of "authoritativeness". Application developers should think about what data is core to their application. What data is the application authoritative for? If an application isn't authoritative over an attribute, it probably shouldn't be storing or managing that attribute. Instead, this "non-core" attribute should be obtained from the "identity network" (or metaverse as Kim calls it). An application's "core" data should only be the data for which the application is authoritative. In that sense, I guess I may be saying the opposite of Kim. But the idea is the same, an application should have a sense of what is core and not core.
  
• Applications need to register the identity data they consume, use, and update. Additionally, applications need to register the transactions they intend to perform with that data. This enables identity services to be built around an application that can be performant to the application's requirements.
  

What I have just described was actually part of the original inspiration behind CARML(Client Attributes Requirements Markup Language) put forward by Oracle that the Liberty Alliance is working on now. It was our belief that in order to enable applications to connect to diverse identity service infrastructures, something like CARML was needed to make the identity network both possible, adaptive, and intelligent.

But, while CARML was cool in itself, the business benefit to CARML was that knowing how an application consumes and uses identity data would not only help the identity network but it would also greatly improve the ability of auditors to perform privacy impact assessments.

We've recently begun an open source project at OpenLiberty called the IGF Attribute Services API that does exactly what Kim is talking about (by the way, I'm looking for nominations for a cool project name - let me know your thoughts). The Attribute Services API is still in early development stages - we are only at milestone 0.3. But that said, now is a great time for broader input. I think we are beginning to show that a fully de-coupled API that meets the requirements above is possible and dramatically easier to use and yet at the same time, much more privacy centric in its approach.

The key to all of this is to get as many applications as possible in the future to support CARML as a standard form of declaration. CARML makes it possible for identity infrastructure product vendors and service providers to build the identity network or next generation of metadirectory as described by Kim.

Working on it

Pamela Dingle writes an appeal to Enterprise Application Vendors in her recent post. From my perspective she hit's the nail on the head for enterprise vendors:

I believe we’ve hit a crossroads, my friends. Here’s what’s happening. We have a groundswell of support and interest in technologies that reduce the need for passwords in the Enterprise. Some of these technologies have been around awhile. Some of them are new. All of them want to integrate with YOU, the Enterprise Application. Action is necessary in the immediate future.

In talking to your fellow vendors, I can almost feel the panic - you can’t possibly support all of the new technologies coming out, you aren’t even supporting technologies that are years old — how do you choose?

Pamela is right. How will the market evolve if we can't even get the basics agreed upon. It's clearly a market adoption issue, but this is going to take quite some time. Pam suggests:

My preference? Set up your application so that the customers can write their own identity front-end integrations. Allow your client base to directly underwrite & collaborate on support for the technologies that they need.

Obviously, Oracle has been thinking about this problem too for some time. However, there is a strong feeling that the solution has to be standards based and available in an open way.

This in part was the motivation behind the IGF project at OpenLiberty. You see, the idea isn't just to support identity privacy and governance, but to create an application identity API (aka Attribute Services API) that allows applications to become decoupled these issues of having to support all the protocols and technologies out there. It lets the enterprise's decide how and when applications should access identity information and by what means.

p.s. I know, I know...the web site isn't that great yet. It still needs a lot of work and many improved explanations. It also goes without saying we need more than just a Java implementation. Any volunteers interested in building this community and addressing Pamela's challenge?

A Great Higgins F2F!

Last week, I had an interesting week at the Higgins F2F in Provo, Utah.

Higgins is really starting to evolve in a nice way to be not only an excellent identity selector, but also an open source implementation of a multi-protocol Identity Provider.

Higgins also has an growing role as an incredibly useful code library for both applications developers and Identity service provider developers. This latter part is why I found myself flying out to Provo in the middle of winter to meet at the Higgins F2F.

As many of you know, I'm currently working on the Attribute Services API for OpenLiberty. At this stage, I'm getting close to publishing the developer APIs that most apps developers will be able to use. But, the plumbing has yet to be built. Higgins IdAS looks like it will fill those requirements nicely!

The challenge will be how to get the IGF privacy metadata properly handled by the Higgins IdAS providers (not to mention how to profile IGF on all of the various protocols). We had a lot of great discussion - and it looks positive that we'll be able to use the existing IdAS APIs to get what we need done.

During the meeting, we shared a lot of requirements and in particular discussed on IGF metadata could be handled by IdAS. The discussion was incredibly useful, and I'm excited to now begin the process of literally pluggins these two projects together!

Another interesting discussion was the topic of access control. XACML is an evolving possibility. It is certainly something we've been looking at for IGF since AAPML is based on a profile of XACML.

My thanks to Novell, Paul, and Mary for hosting and organizing the event, and especially to Jim, who took a bunch of us intrepid geeks out to the mountains on Friday to go skiing. It was nice to spend the day building friendships and solidifying our open source "community" relationship. The knee-deep fluffy white powder snow was definitely a truly epic bonus!

Thanks Jim!

Thinking About An Identity Services API

My colleague at Oracle, Nishant Kaushik, was asking me about whether I knew if something was going on to develop a high-level API for Identity Services in the open source community. I realized that in a way, my work at Open Liberty on the implementation of the CARML API for the Identity Governance Framework was in fact turning out to be the startings of that exact API. From the developer's perspective, we're not building an IGF API, we're building an attribute/identity services API of which identity policy is only one of the many services needed.

The focus of the Open Liberty IGF project has been to demonstrate and provide libraries for using IGF, the issue I have run into, is that this project also needs a complete set of Identity Services. It needs to work with all the popular protocols (which is why working with a protocol specific API isn't good enough and why we're using Higgins IdAS to build on top of). It needs to deal with a wide variety web application needs and deployment environments. What started out as simply an implementation of IGF is definitely much bigger.

I would like to invite anybody interested in identity services to join the IGF Development Discussion group and add your thoughts. Should we broaden the direction of the IGF development to be more generic? Should we even rename or relocate the project? What do you think should be included in Identity Services. I know opinions vary widely on what Identity Services is. But this is exactly why collaborative input is needed now. Are you interested in getting involved? If so, feel free to respond to this post, or add your thoughts to the official development list!

Updates on OpenLiberty IGF Developer API

The IGF wiki has been updated on the openLiberty web site. In particular check out the new attribute services developer API.

For all you application developers trying to figure out what the best way to access identity information. What protocols you should use, the schemas that should be followed? The Attribute Services API is intended to isolate you from all the complexities of deployment. Check it out. Tell me what you think.