Three Types of Keystone Users

Keystone supports multiple backend for Identity.  While SQL is the default, LDAP is one of the most used.  With Federation protocols, the user data won’t even be stored in the identity backend at all.  All three of these approaches have different use cases, and all work together.  The way that that I’ve come to think of them is as  three types of Keystone users:  employees, partners, and customers.  Take the following as a metaphor, not literal  truth.

Continue reading

Who holds the keys to the Kingdom

During the years I worked as a Web application developer, it seemed like every application had its own authentication mechanism. An application developer is thinking in terms of the domain model for their application whether it be eCommerce, Systems management, photography, or weblogs. Identity Management is a cross cutting concern, and it is hard to get right. Why, then, do so many applications have “user” tables in their databases?
Continue reading

Wizard Woodcarving

After reading The Hobbit to my sons, my younger guy requested his favorite character. Quite pleased with how this grey pilgrim turned out.

Presentation on Keystone Deepdive and Folsom

There is not a lot of text: I tend to keep my presentations as a visual mnemonic for the topics being discussed.

Let me know if you want to steal any of the images I created. I have them all as SVG, and the UML diagrams came out of ArgoUML.

Most of the Creative Commons images were found on, attributions at the end.

Cloud Narrative

Identity Management (IdM) needs change as an organization grows in size. For an example, I’ll describe a fictional company, and take it from the smallest to largest stages. While, to some degree, the industry of this firm really doesn’t matter, I am going to use a small import business started by a single individual and scale it up to a multinational corporation. As the organization grows in size, the technical needs will drive the scope and scale of the identity management solutions required.
(This is my writing Cross posted from the FreeIPA wiki)

Continue reading

WebUI diagrams

I gave a presentation to some of the other teams at Red Hat about our approach on the WebUI.  Here are a couple of the graphics from the presentation.

This is the  “class” diagram for our UI toolkit.  It doesn’t show everything.  Instead it is intended to orient you to the most important aspects of the toolkit.

WebUI core-classes

WebUI core-classes

Click to see the whole diagram.  The top “swimlane” is the abstractions we provide.  The middle is the classes you’ll want to use when actually designing an application.  The bottom shows the command objects:  there are many instances of these, but with all pretty much the same behavior.  Calling this a class diagram is a stretch, as there are not really classes per-se in Javascript, but out programming approach pretty well mimics what Java or C++ does in overloading virtual functions.  Hence, thinking of them as classes is not a bad idea.


The second is an old-school flow chart.  The Angled boxes indicate IO, the square boxes are browser side operations.

The load of the initial Javascript files is not strictly serial.  It is possible that they overlap, and thus that section is shown happening in parallel.

The bottom of the diagram is pretty much an endless loop.   The yellow box represents the waiting state of the application:  from there you can see the four types of events that change the state of the application.