The Interfederation Problem
Interfederation – the processing of sharing entity metadata between different federations – is intended to both make management of metadata easier for Identity Providers (IdPs) and Service Providers (SPs) and ultimate to allow metadata to flow on a global scale with minimum barriers. eduGAIN was set up with the intention of achieving just those aims, however eduGAIN is built on top of an existing architecture of federations that have grown up organically in different countries.
Over the last year, eduGAIN has seen an increasing number of entities being added to its metadata as more and more member organisations look to ramp-up their contributions to eduGAIN. This has inevitably led to problems as slight differences in national approaches cause inconsistencies at an international scale. Many of these problems have clear solutions and should be seen as a positive move towards greater compatibility, it is inevitable that some changes and compromises will need to be made within our federations to support the interfederation process.
Issues with metadata in eduGAIN broadly fall in to three categories:
- Issues relating to eligibility and entity types: the “Entity Type” problem.
- Issues relating to the same entity having different metadata within different federations: the “Same but Different” problem.
- Issues relating to different approaches to managing upstream and downstream metadata: the “Metadata Flow” problem.
Different approaches are needed in order to improve problems in these areas.
1. The “Entity Type” Problem
Different federations have different approaches to tackling the problem of who is allowed to join a federation. Eligibility requirements are normally referenced in Federation Policy, with a more detailed eligibility process detailed in separation information held on a federation website. This in itself does not create much of a problem – REFEDS carried out an extensive review of federation policies in 2012 and concluded that whilst different approaches to policy were in place there was little or no overall impact on interfederation from these different approaches.
The main problem with different approaches to eligibility is that the process of defining eligibility is both entirely manual and not expressed in metadata in any way. Appearance within the metadata feed of any given federation implies that an entity has passed the eligibility criteria of that federation – but there is not information as to why this might be the case. There is no way of indicating what sort of characteristics any entity might have to help it pass the eligibility test, or in other words what sort of entity type this is.
For federations that do have policies that exclude certain entity types – for example services selling discount offers to students – there is no automated way of detecting such services as they enter an interfederation feed and manually checking entities as they appear will simply not scale in an interfederation context. A different approach to classifying entity types is needed.
The concept of adding tags to entity metadata is not a new one. The UK federation has for some time added flags to indicate certain information about any given entity such as complying with certain assurance criteria and the wish to be hidden from the discovery service. REFEDS has recently introduced standardised Entity Categories to help support this process of adding tags to metadata, with a specific focus on tags to help institutions make sensible decisions about attribute release.
Tagging could be extended further to support federations that need to make eligibility decisions, whether via the Entity Category approach or other flags in metadata. The community has started to discuss places where eligibility problems could be addressed in a scalable manner. Core problems here would be that entities may be reluctant to receive a tag if they felt this would exclude them from any given audience.
2. The “Same but Different” Problem
The fully operational eduGAIN service is still a relatively new kid on the block in terms of supporting research and education federations. In order to distribute metadata across the many different federations in service to date, Service Providers (and in some cases Identity Providers) have simply had to join multiple federations. This has led to a scenario where the same entity has different sets of metadata associated with it in different federations.
These differences can be for a variety of reasons. In some cases, it is simply that metadata has been refreshed in some federations and not others leading to differences in factual information such as contact details or valid certificates. In other cases, the differences are purposeful; Service Providers may wish to have different contact details in different countries or may want to express different endpoints to support different discovery processes or indeed to support differing technical requirements in different federations.
When the same entity is registered multiple times within eduGAIN only one of the instances is published, using a simple decision process where the instance put in eduGAIN first is given priority. This can lead to problems with the same entity having different metadata within a federation’s local metadata and in their eduGAIN feed.
Some simple steps have been proposed to help address this problem. eduGAIN and REFEDS are looking at creating a simple “eduGAIN Ready” check-list for entities to help them achieve the most elegant looking set of metadata for international distribution as part of a general Metadata Improvement Plan. As part of this work, entities will also be encouraged to remove legacy instances of metadata from federations once they have successfully seen their metadata flow via eduGAIN. Achieving this aim is impacted in turn by the “Metadata Flow” problem.
3. The “Metadata Flow” Problem
A phrase commonly heard in relation to research and education federations is “let the metadata flow”. This refers to the idea that metadata should be evenly distributed across federations and reach Identity Providers and Service Providers with reasonable reciprocity with as few barriers as possible put in the way that might prevent entities from reaching each other. Various differing approaches and interpretations of eduGAIN by federations are currently creating barriers to this flow.
Federations are adopting different approaches to “opt-in / opt-out” of eduGAIN, meaning that a Service Provider entering eduGAIN has no guarantees, and indeed no easy way of checking, whether any given Identity Provider will be seeing their metadata – and vice versa.
Federations have also made different decisions about how to distribute “downstream” eduGAIN metadata – i.e. the global eduGAIN metata aggregation – back to their members. Some federations tag eduGAIN metadata within their local metadata feed, some distribute a separate eduGAIN metadata feed that an entity must consume alongside local information and some offer bespoke “cherry-picked” eduGAIN feeds to different members or need to configure entities received via eduGAIN locally on a case-by-case basis. Many of these approaches cause disruption to the metadata flow and the different approaches taken make it difficult for entities to understand what information is being received where.
REFEDS is looking to standardise and document different approaches to operational practice via the introduction of the Federation Operator Practice template, and in particular work to standardise information in the Metadata Registration Practice Statement.
There is more work to be done to make interfederation a full operational reality but federations are well on the way to making this happen. If you would like to know more about REFEDS work or the problems and issues being tackled in the interfederation space, please do not hesitate to contact us.