September 2009

It’s my pleasure to inform you that Kalmar Union, the
confederation of Nordic academic identity federations,
is operational and today published in the NORDUnet conference.

Press release:

Kalmar currently covers all Danish and Norwegian universities,
6 Swedish universities and 1 Finnish university. 10
Service Providers are registered to the confederation.

NORDUnet2009 presentation with lots of help from Mikael Linden, David Simonsen and Andreas Solberg.

Feide has an architecture where one Identity Provider has multiple Authentication Points behind the IdP.  Authentication Points are implemented as LDAPs, and all the LDAP servers are using the same norEdu* schemas (norEduPerson, norEduOrg, norEduOrgUnit) building on  eduPerson which builds on inetOrgPerson. This sounds complicated, but in real life this amounts to minimum technical overhead, as the only changes needed in the local technical infrastructure are

  • adding the norEdu* schema to the existing LDAP (since every single institution has at least one LDAP)
  • regular updates of the LDAP from authoritative sources (student registry, payroll systems, school management systems etc)
  • configuring filters for the information from authoritative sources
  • installing SSL/TLS on their LDAP, and giving Feide the certificate information

The identity management itself is mostly an administrative process, and this is the part of process re-engineering and auditing that takes time.

A university or college or school owner have their own realm. Each realm provisions users to their own LDAP, and the IdP looks at all the realms.

Why, oh why, is this not supported in off-the shelf software?  Are there no mergers in business outside higher education?  It is a simple mechanism that allows for integration of several user groupings, and we know from experience that it works.

Interoperability challenges get bigger when crossing security boundaries or organizational boundaries. Working from home on a non-secure PC/Mac by definition cross a security boundary before reaching anyone, and places high requirements when attempting peer to peer communication. Communicating with a central server is less complicated, as the number of boundaries crossed is limited.

In the context of web conferencing solutions that may support remote teaching, there are challenges related to interoperability both within the application area and with the rest of the infrastructure:

  • federated login: more and more products claim to be SAML2.0, or at least Shibboleth-capable
  • supporting pre-defined groups, for example by integrating from a learning management system and reusing the predefined course groupings
  • calendar integration, or integration with other collaboration tools
  • chat integration, supporting the tools familiar to the end user
  • user interface familiarity: standard place for toolbars and icons, familiar icons, comprehensible vocabulary
  • integration with the phone infrastructure: could be by SIP or through MCUs, should speak well with plain old telephony

Vendor lock-in is a danger when choosing products, and such lock-in may manifest in different ways for desktop conferencing:

  • software installation: requiring everyone participating in a meeting to download and install specific software on their PC/Mac
  • lock-out of other solutions: being unable to participate in other meeting solutions as the PC/Mac is pre-configured for a specific solution and the other solutions may have conflicting requirements that are difficult for the end user to sort out
  • data rot: stored content/data, developed for a specific whiteboard or document format, get inaccessible as the contract expires
  • no sharing of information: impossible to extract content/data to other systems

Software installation is mostly solved by using a central server for multi-person meetings, where the participants download flash or java capable software to their computers.  Any researcher participating in international projects has come across at least one non interoperable web/video conferencing solution provided by the lead partner in the project, and being required to download software to be fiddled with, often leading to non-functional sound, video or chat which then again leads to non-productive meetings.

Some interoperability challenges may be solved on the organizational level for applications residing inside the organizational security boundary. Traditional video conferencing, with pre-configured meeting rooms, is an example where dedicated staff and pre-punched holes in firewalls make it possible to use not-really-interoperable products across organizational borders.

Open standards, and consistent implementation of these, play a key role in interoperable collaborative solutions. The current technology situation makes it necessary to test products for compliance with open standards.  And the current audio/video driver software wars make Linux a hardship with regards to open interoperable video conferencing solutions that will work from home.

I wish there was a silver bullet allowing several of us to speak to each other and listen to others and look at slides and drawings, even in a multi-vendor environment.  I had the same wish 15 years ago.  At least the user interfaces have improved, and USB has added a layer of indirection that solves some of the hardware issues.  I wish that reality would shatter my video conferencing cynicism.