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.
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
writers, which is precisely the sort of thing that
LDAP servers allow us to do.
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.
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.
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.
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
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.)
Photo by Rakuten, Inc. Available under Creative Commons