If for example I want to roll out web conferencing tools to a couple of hundred thousand users, and all these users have a federated ID linked with a good attribute set, why should I have to worry about provisioning?  I can have my users log in, transfer the appropriate information as attributes, and then things should work.  And there are at least 15 million federated user in the higher education sector alone, across the federations that we know of.  Why are the solutions emerging so slowly in this market?

We spent the last decade fixing availability of attributes and getting federated IDs deployed, and I would like to reap the benefits I know are lurking in the cloud from this investment:

  1. Federated login without letting the applications see the passwords
  2. Let real-time attribute transfer replace provisioning
  3. Being able to let federated widgets play together to let components form a coherent service, easing integration

Getting back to my current use case on web conferencing tools, I get really frustrated.  Not only with the bad audio, which is seriously annoying, but with the cumbersome deployment issues when rolling out in large communities. As far as I know, there is only Cisco WebEx of the web conferencing tools that have federated login operational on their standard federated plattform.  Some other vendors and solutions are actively investigating federated ID, and have customers who have done on-site extensions with federated login.  Some comments on web meeting solutions I have encountered in the past few months

  • Adobe Connect, a popular solution in higher education for web meetings does not support federated login on their hosted environment.  An example a properly behaved system  is SUNETs Adobe Connect installation where SUNET has added federated login with SWAMID and support for attributes.  Why not on the hosted service?  Will it be too much trouble to get a large amount of users?
  • Elluminate is working closely with several major LMS suppliers (it was bought by Blackboard this summer), and has functionality that is useful for education.  But no federated login – yet.
  • Nefsis is highly loved by the teaching community using it. I have not been testing this system myself.  There is no federated login.
  • NTR-meeting is a lightweight solution for web meetings, simple and easy to use.  Would be even easier if it had federated login.
  • BigBlueButton is open software for web meetings.  Not quite in production yet, and has no federated login.
  • DimDim is also used for distance lectures.  But it has no federated login.
  • Vidyo is tested (I have not tested it myself) by several interested parties.  No federated login reported.
  • EVO from the high performance computing crowd.  Developped within our own community.  Still no federated login.
  • Microsoft OCS may support federated login (codename Geneva), but when I talk to the local guys about this, we have so far spent most of our time explaining that federation does not imply collating Active Directory trees, but is Something Web with XML.

And the service from Skype, useable with good sound when everything else fail: no federated login.  On the other hand, I did not expect Skype to have federated login, as they operate in an environment on individual users.  The ones named on the list above try to deliver services to organizations.  Deployment without federated login is a lot more work than with federated login.  On the other hand, the extra work falls mostly on the deploying organization, so maybe that is why the service providers do not care.


Student mobility is on the raise in Europe, and the Bologna process is moving along.  Student records need to move with the students, and students need access across borders (and federations).

RS3G (Rome Student Systems and Standards Group) is “a self-established group of software implementers and stakeholders in the European Higher Education domain which is focused on contributing to the definition and adoption of standards and procedures for the exchange of data to facilitate student mobility and lifelong learning.”

Every year large numbers of students move from one institution to another, and their student records need to move with them. Today this happens on paper, which is silly given that all the information is treated electronically at both universities. The RS3G has set up a mobility project to sort out these issues and FS (student registry in Norway) is chairing the architectural work.  The basic experiences that lies at the hearth of the project is explained in a EUNIS paper Web-services for exchange of data on cooperation and mobility in  higher education institutions.

Project goals include:

  • Reduce administrative inefficiencies/problems in handling mobility data and procedures (intra-university)
  • Streamline the communication flow among partner institutions (inter-universities)
  • Interconnect universities in a international network
  • Digitize mobility documents (secure, authentic, transparent, tamper-proof)
  • Produce reliable and accessible mobility statistics (EC interest)

This work solves a concrete problem in the identity layer today, but a solution will also put us one step closer to solving the provisioning issues, and it may help on the overall person-information flow that we have started work on with the standardization effort on PIFU (NS-4170). Our goal is to make integration of systems easier, by working on interfaces for data exchange.

Some interesting postings om attribute aggregation, both grew out of work on virtual organizations

Attribute aggregation is collating attributes about a user account from multiple sources.  In the case of virtual organizations and their use of specific web resources with federated login, this boils down to: how do I add an eduPersonEntitlement maintained by VO-whatnot to the information about the user from his university.

The possibilities and the doors opened with attribute aggregation are enticing and slightly frightening. My international research project site getting an attribute from the project manager and federated login from my employer will work fine.  That is not scary. The employee web site may be able to download info about my color preferences from nerdy-color-repository.  That is not so scary.  When my son starts school next year, I may log in to the learning management system, getting the login from the national eID, the association with my child from an attribute authority and information about his attributes from Feide.  That is cool and not scary at all.  The pizza place getting info about my phone number, cross referencing with payment history, getting info on pavement status in my neighbourhood and refusing to dispatch pizza to the people helping me move my piano.  That is scary.  And partly why the user interface for aggregation, informed choices, privacy, security testing and a lot of other issues needs more work.

Higher education and research federations are using the eduPerson schema, where eduPersonAffiliation and eduPersonScopedAffiliation is the basic way of handling roles. The only well-defined roles consist of the vocabulary for eduPersonAffiliation, with some local extensions.  Some federations have defined other well-scoped vocabularies for roles in special attributes.  eduPersonAffiliation is used in a large number of applications.

I would like to see some more simple roles for learning, staff duties and high performance computing.  Currently I am trying to gather the information that will make it possible to make some small steps towards semantic interoperability for roles within our community, as requested in a recent report on Strategies for shared administrative services in Norway (Norwegian only) and by several universities.

Learning roles should take up the vocabulary defined in IMS Enterprise, which is used for populating e-learning support systems (Fronter, It’sLearning) for courses: Learner, Instructor, Content Developer, Member, Manager, Mentor, Administrator, TeachingAssistant.  These values are also used in Norwegian Standard NS4170, Person Information Flow in Education (PIFU).  Mappings from the roles in FS, the shared Student Registry are well-defined.

Research roles include project manager, project participant, main author and co-author.  Other research roles may be related to the grid community.  Work on Short Lived Credential Service (SLCS) based on federated login is going to give us more information on the role requirements from the grid community.

Administrative staff comes in the flavors of: finance officers, HR, archivists, IT and student registrars.  All of these groups are present in universities and colleges, and the functions of a staff member is linked to a specific place in the organizational chart.  This should, in theory, make it possible to identify roles and use these roles to limit access to specific services.

Currently the web services seems able to handle information about a single end user, so the roles must be mapped onto each user account (probably in LDAP or such-like).  In addition to this information, there should be restricted meta-information about the groupings/roles themselves available.  And having the roles represented as groups (isMemberOf) in the local LDAPs could be helpful.

Earlier attempts to define semantics for shared roles has failed, mostly due to the inability to define a problem statement.  My problem statement so far:  Define semantics for shared roles that are preventing interoperability or administration of security domains in key IT services for staff administrative services, learning and research in Norway’s higher education.

Still work to do on these issues…  to be continued

Norway was password protected before Schengen (and 9/11), when they standardized border crossings and security procedures.  You walked in to the passport control, briskly, and announced “Norsk”.  If you could pronounce it, you earned the right to enter the country.   This procedure worked nicely if you were white skinned, or obviously belonged with some white skin people (all Norwegians are tall, blond and blue eyed; except some of us).  The entry procedure was similar to the Shibboleth described in chapter 12, Book of Judges.  “Norsk” (Norwegian) is remarkably hard to pronounce for foreigners, including Danes and Swedes.  Since a language is a dialect with an army, Norwegian is a language separate from Danish and Swedish.

I am currently abroad, in the fair mountains of Andalucia, visiting my in-laws who spend their winters here.  Travelling with children involves more paper work than it used to, when I was young.  Our two sons had to get a passport each, even if Spain is part of Schengen where (in theory) there is no need to carry a passport when crossing borders from Norway.  When we return, they are not likely to check at the border, since the passport control has been delegated to the air line operators. Delegation of authorization to the access point is common procedure, but leads to differences in the pragmatic day to day implementation of the authorization (as those of us trying to travel with KLM to the Netherlands without a passport knows,  even if we had plenty of other valid ID).

The formal requirement for travelling is having identification papers, but in practice the only identity paper available for small children is a passport.  Back when I was a child, you put the names of children into the parent’s passport, and then you could take the children with you.  This was called “writing the child into the passport”, and was sufficient security until someone discovered that most children have more than one parent (and some parents have multiple passports).  Then it was decided to treat children like persons, with regards to passports.

I know a Polish linguist who regularly entered the country by using the password procedure (or by putting on T-shirts proclaiming the benefit of Nynorsk and sheeps heads, something only indigines from Voss does in public) in the late 1980’s.  Using passwords is of course vunerable to attacs, but the risk from visiting linguists could be deemed low enough to be acceptable.   Providing background discussion to the risk analysis is rarely done, and this impedes the transparency of the authentication and identity solutions we encounter.