Uncategorized

 

GEANT

This post is part of a formal deliverable of the GÉANT GN4 “Trust and Identity Harmonisation” task, which was funded for a one-year period from May 2015 – April 2016.  A series of blogposts will appear here on the REFEDS blog to help more widely disseminate the work of the task and progress achieved.  More information can be found on the GÉANT wiki. With thanks to Christos Kanellopoulos for the text on STORK developments.

The aim of the “interoperability” subtask was to develop sustainable approaches to interoperability with e-Gov, social media identity frameworks and other lifelong identity initiatives, especially those of NRENs. The work focused on:

  1. Completion of pilot use cases with STORK2.0 and a roadmap towards sustainable long-term implementation based on experience gained during GN3plus.
  2. Engagement with standards areas, such as Kantara on behalf of eduGAIN.
  3. Development of results from GN3 JRA3 as appropriate e.g. Federation Lab.

Pilots with STORK and e-GOV

Secure idenTity acrOss boRders linKed (STORK) and its evolution STORK 2.0 were EU co-funded projects under the ICT Policy Support Programme of the Competitiveness and Innovation Framework Programme (CIP). The aim of the STORK project was to establish a European eID Interoperability Platform pilot that to allow citizens to establish new e-relations across borders just by presenting their national eID. STORK 2.0 aimed to contribute to the realisation of a single European electronic identification and authentication area. The STORK 2.0 consortium was composed of 19 different countries (Austria, Belgium, Czech Republic, Estonia, France, Greece, Iceland, Italy, Lithuania, Luxembourg, Netherlands, Portugal, Slovakia, Slovenia, Spain, Sweden, Switzerland, Turkey, and the United Kingdom) and provided a distributed pilot infrastructure to enable cross-border interoperability of existing national electronic identity schemes. A few public authorities usually performed the role of Identity providers in STORK2.0 in each country (from 1 to 80 according to Member State’ organisation) for a total of over 130 IdPs at European level. At the end of STORK 2.0, the outcomes of the STORK 1.0 and STORK 2.0 projects were passed on to the Connecting Europe Facility, which is responsible for defining the building blocks for eID, eSIGNATURE, eDELIVERY, eINVOICING and eTRANSLATION within eIDAS.

STORK 1.0 and 2.0 are both based on SAML2.0, the same protocol used in the academic federations in eduGAIN. As SAML 2.0 leaves implementers many options, (e.g. on how to pass attributes, what bindings to use, how to use PKI, what should be signed and what should be encrypted), the actual implementations in eduGAIN and STORK are not interoperable out of the box.

The Interoperability subtask of the Trust and Identity Harmonization task, looked at the differences between the SAML2Int standard and the STORK2.0 specification and piloted possible scenarios for the interoperability between the implementations.

In GN4-1 the work started in previous JRA development work during GN3plus on the pilot use cases with STORK 2.0 was completed. Two high-level use cases were identified and developed:

  • Use case 1: A user with a STORK eID accesses a service provided by an SP in one of the eduGAIN Federations.
  • Use case 2: A user with an account on an IdP in one of the eduGAIN Federations accesses a service provided by STORK in one of the STORK enabled member states.

To enable interoperation, a new proxy element, eduPEPS, was added. eduPEPS can be situated between a STORK federation and an eduGAIN federation and acts as a protocol translation bridge, while at the same time providing a trusted entity for both the STORK and the eduGAIN federations.

The eduPEPS service is comprised of two components, the eduPEPS Proxy and the eduPEPS Attribute Translation Library. The eduPEPS Proxy provides the necessary interfaces to be able to act as a proxy between entities in the eduGAIN and STORK Federations. In academic federations, the eduPEPS service can participate as a virtual SP or IdP, with a built-in Discovery Service, depending on whether a user is authenticated on an academic IdP or using her governmental eID. In a STORK infrastructure, eduPEPS can participate as a PEPS or IdP, or as an Attribute Authority or SP, depending again on the actual user flows and the chosen deployment scenario. The eduPEPS Translation Library is an integral part of the eduPEPS service and provides configurable attribute mappings. Primarily it is used to map between the eduPerson schema and the STORK attribute schema for Academia, but it can easily be configured to map between any kinds of attribute schemas.

The pilot eduPEPS service was deployed and tested in a testbed environment comprised of:

  • an SP using the SAML2Int profile operated by GRNET in Greece.
  • an SP using the STORK SP interface operated by the University of Murcia in Spain.
  • an IdP connected to the GRNET Academic Federation.
  • a test STORK PEPS installation operated by the University of Murcia in Spain.
  • the pre-production STORK PEPS installation operated by the Ministry of Interior and Administrative Reconstruction in Greece.

Two deployment scenarios for the eduPEPS service have been identified. In the first scenario, the eduPEPS service is deployed as a bridging element between the academic federations in eduGAIN and the STORK infrastructures in the European member states. In the second scenario, the eduPEPS service is deployed within the member states and acts as a gateway between the STORK infrastructure and the academic federation in each member state. Both these scenarios have pros and cons but allow the interoperation between the academic federations in eduGAIN and the STORK infrastructures, without having to introduce multiple software stacks for federated access at the participating SPs.

During development of the eduPEPS service, the STORK PEPS pilot implementation presented a moving target. Until the last month of the STORK 2.0 project, new functionality was being added to the STORK 2.0 PEPS, which in many cases was not backwards compatible with the previous versions of STORK. Furthermore, some of the most advanced scenarios that were described in STORK 2.0, such as cross-border attribute aggregation, were never tried in real-life implementation. Under these circumstances, the proof-of-concept implementation of the eduPEPS service had to rely on assumptions about the STORK 2.0 functionality that could not be fully tested. Furthermore, when the STORK 2.0 project ended in September 2015, it handed over its outcomes to CEF, which is responsible for the definition of the building blocks for eID, eSIGNATURE, eDELIVERY, eINVOICING and eTRANSLATION within eIDAS. The eID building blocks for eIDAS are expected to follow the STORK architecture to a certain extent, especially regarding the cross-border authentication interoperation aspects.

Federation Lab and Federation Statistics

The Trust and Identity Harmonisation task has been working with FedLab, which was developed as part of previous JRA work during GN3, to pilot its approaches to testing entities for interoperability and compatibility.  The aim of this work was to define recommendations on future service models for FedLab.

One of the most often requested features for FedLab that is not found in the current toolset and does not fit well with the scope of that toolset, is the ongoing need for federation statistics and high-level monitoring of the number of authentications carried out by federations.  Obtaining such data is problematic for most federations as this information is typically only captured at the institutional level.

The subtask also carried out an initial review of the current status of statistics gathering within federations, discussing with federation operators their current and future needs and potential developments in this respect.  The results were included in a white paper on Issues and Solutions for SAML Identity Federation Statistics which identifies some pragmatic first steps to demonstrate the value of statistics and thereby encourage greater engagement with the topic.

Coherent statistical information remains a significant issue for federations and federation funders, and at the time of writing is not an area that is mature enough for an interoperable approach. Individual national approaches are sparse and do not standardise the type of information requested, and different architectures pose radically different challenges for data collection and aggregation.

Recommendations

The interoperability subtask item has drawn up the following recommendations:

  • Complete the SAML F-TICKS specification to make it deployable.
  • A central service to aggregate statistics from federations in the same model as monitor.eduroam.org should be developed, starting with hub-and-spoke/centralised federations as a pragmatic baseline.
  • Further work should be done to develop RAPTOR based on the Edugate approach used in Ireland . This depends heavily on increasing uptake of the RAPTOR tool by organisations.
  • More effort should be directed at enabling IdPs to commit time to developments such as support for aggregated statistics. GÉANT should look at producing a set of recommendations for IdPs’ local development plans highlighting areas in which IdPs should be investing time and effort in over the next one or two years in an accessible way, for use by senior management at campuses.
  • REFEDS / eduGAIN should look at tracking changes in entity information over time in MET and eduGAIN tools.
  • Work with the STORK 2.0 project has shown that the technical interoperation between the academic federations in eduGAIN and the eGOV eIDs and services is achievable. As eIDAS is being implemented by the member states, close collaboration with the eIDAS Task Force and CEF should continue towards achieving policy and technical interoperation.