This more complex example describes how the InternetWide Indentity Framework can help to create a planning system with Kanban cards, with full support for sharing cards, even across realms.

Before ARPA2, cards have already showed their worth, but sharing them was difficult, and keeping them is sync across localities was impossible:

The trick to distributed collaboration is always the use of standardised protocols. Kanban planning applications, with their flexible card structures, are eminently suitable for storage in an LDAP repository, which is a very solid standard format for storing objects with any number of attributes, and with per-object typing to help structure those.

The diagram shows a Card structure (which might be shared) and a View on a card. The former might be stored in a general repository for a card application, while the second is stored under a card-viewing application of a particular user or group. When the link between these two takes the form of an LDAP distinguishedName, then distribution has become trival. Moreover, LDAP supports subscriptions to changes through the SyncRepl mechanism, so it is even possible to see new objects being added or removed.

Securing Access

The View instances would normally be stored in a subtree under the object in LDAP that represents a user or group; this object can then be manipulated by that user or group to change the appearance of the card.

The security of Card objects are a different matter altogether, because they are (in general) considered distributed, and made available from a generic pile of objects. That pile however, could simply be programmed to be available to the identities mentioned under readers and writers, which is precisely the sort of thing that LDAP servers allow us to do.

So, what we need in the LDAP servers is the form of authentication and authorisation that we already described for the SMTP examples before. This turns out to be relatively simple.

First, there needs to be a method of establishing a (remote) identity. Since LDAP has a well-defined STARTTLS extension, nothing is simpler than starting up TLS. This can even be done very quickly when TLS-KDH is used.

The next step is to perform authorisation. This will usually consist of two phases.

1. There may be overall access requirements, which would use Diameter or RADIUS and this may involve renaming a user to a local alias as it is done for all services offered by a realm.

2. There would be access settings on individual cards, as is desirable from a privacy perspective. This is done in the owner (who created the card and may delete it) , the readers (who may view the card) and writers (who may view and update the card).

The first phase would use a resource-identifier for a collection of cards that may span many users, groups and realms; to check for access, an attempt is made to access the owner as a communication peer. This results in permissions to the card collection; it may keep the remote's identity or it may set a local identity, possibly even a user name under a local realm for remote users as distinguishable group members.

This first phase is the only thing that is not currently very common in LDAP. Basically, this is a SASL EXTERNAL access method -- which is usually implemented in libraries that span across many more services than mere LDAP. In short, it is a reasonable extension to be made, and followed by the commonly available LDAP access control lists.

What this demonstrates, is how powerful the model that we propose actually is; it plugs into generic plugholes and fulfills purposes and yet... it gives a very powerful model for identity management, and it clearly demonstrates the power of our Bring Your Own IDentity principle.

Dedicated Applications

An application that is dedicated to viewing these cards for any given user would connect to each LDAP server that needs it, and it would acquire any of the desired tickets automatically, based on the single sign-on facility of Kerberos.

So, you login at the beginning of the day, you start your application with a reference to the LDAP collection holding your View objects, and from there the underlying Card objects will be automatically retrieved.

Using LDAP to its best, it is also possible to subscribe for updated. That is possible through the SyncRepl mechanism, which comes down to "search for objects that match certain criteria; and when done, keep me posted on any new or removed objects that match these search criteria" -- and the result is fairly dramatic, namely almost immediate updates when a shared Card is changed. In case of a group view, even changes to View objects will be shared in the same fashion.

Connection to the Web

Web sites are the lowest common denominator GUI that many users have gotten accustomed to. It would be unpractical to design a system that could not also be shown in this interface, even if it can technically be a bit impaired when it comes to such distributed realtime mechanisms.

It is quite possible to build a web interface that connects to LDAP and delivers its contained objects over AJAX, JSON or any other format du jour. This is something we've done before in the Crank component in the SteamWorks project, for example.

It is a little more complicated to provide a web server with tickets to the backend servers however; but this too can be arranged, at least when the TLS-KDH secure transport is being used. The mechanism would then be to insert backend tickets inside the HTTPS ticket. This is a generally useful mechanism, also for popular things such as WebMail, so the chances of adoption are relatively good. (No certainty on that yet, however.)