In this post we present a (very) brief description of the topics and the results presented in this Second Sprint Demo on May 14th.
The next Sprint Demo is planned the week after TNC on June 25th. Don’t miss it!
Community tagging a.k.a. Pixie Dusting
Research communities have described a need to express and potentially share certain trust marks on entities, both Identity Providers (IdPs) and Service Providers (SPs). These trust marks may differ from (existing) trust marks issued by Identity Federations. Such trust marks might also be put in to complement existing ones, in case the federation operator does not (yet) support these, like for example in the case of SIRTFI.
This Incubator topic tries to first of all implement a technical solution that matches the requirements as described by the SIRTFI community. It investigates usability of the solution for research communities and the impact of the solution for Identity Federations. It would like to also explore potential other scenarios where a similar methodology could be used, such as expressing REFEDS multi-factor authentication (MFA) capabilities and in the context of the IdP self assessment tool that was developed in GN42.
This activity does not consider itself at this point with the questions on where and how such a tool would be used in the context of existing trust frameworks. It is understood that is very relevant to the larger picture, but we feel it would be prudent to first create a prototype tool to have a better understanding of the problem space and use that as a starting point for a discussion on the potential impact on the trust framework.
In the second sprint, we have drafted a functional architecture. Two out of three tools we previously selected have been successfully set up and we started reviewing these tools. We further discussed flows and functional requirements and have decided for now use the flow of the eduGAIN Access Check service to allow us to identify an entity owner. Following this sprint we plan the transition of the functional architecture into a technical prototype. Furthermore we will be investigating whether one of the tools qualifies to our needs or if a new, more lightweight pixie dust tool is built. Stay tuned!
The Cryptech HSM incubator topic is investigating the use of CrypTech HSMs for GÉANT services.
The goal of the CrypTech project is to create an open-source hardware cryptographic engine that can be built by anyone from public hardware specifications and open-source firmware and operated without fees of any kind. The team working on the project is a loose international collective of engineers trying to improve assurance and privacy on the Internet. Several GÉANT participating NRENs are investors and participants in this project.
Last year CrypTech developed a first ‘Alpha’ board. More recently Diamond Key Security developed an appliance based on these boards. In this topic we set up these devices to allow for testing and we collect the initial use cases we want to test and the people who will be testing.
During the last sprint, the uses case and requirements analysis started was finalized. The created Deliverable Cryptech HSM UseCases and Requirements was published in the activity wiki. This document provides the basis for the test cases to run against the HSM modules. The deployment of the actual devices was postponed to a later sprint due to a pending software update, which is crucial for the use cases identified.
Due to staffing issues we were not able to make a lot of progress. We have however discussed the current pilot servcie with our GDPR team and are following up on their recommandations. At the same time we were ahppy we were able to onboard two CESNET discovery pilot experts, who will support us making the discovery pilot fly. Welcome on board of the T&I Incubator!
IdP as a Service Business case
The IdP as a Service activity was also handed down from the GN4-2 project. During the GN4-2 project the focus was mostly on creating the technical infrastructure to support IdP as a Service. In this topic we want to finalise the technical setup so it can be used as a demonstrator, and at the same time investigate the business case for such a service in the GÉANT portfolio.
While the first sprint was all about technical issues, the second sprint focused more on business aspects. A business canvas was created to analyse the various aspects that impact an IdP as a Service offering. Furthermore, it was started to compare the two products available in terms of business functionalities and applicability to the needs of our community. To enable an objective comparison, the features required by the T&I community were defined to determine the Minimum Viable Product (MVP). This document will be finished during the next sprint and discussed with the community during TNC19.
ORCID IdP of last resort
Many research collaborations as well as campus services need a solution to deal with guest identity, as in many cases not all users are members of the academic Identity Federations. As a result, several federation operators as well as research collaborations operate IdPs or proxies to allow users to authenticate through external identity providers like social ones. This has led to serious reinventing of the wheel. The need for guest identities burdens the SPs with the integration costs and along the way may force guest users to use specific IdPs as implemented by the SP, which they may not want or may not be able to use, only because the SP decided only to implement a few of these solutions.
In the GN4-2 project a first pilot was run as part of the eduTEAMS activity to investigate if a centralised service could be offered to resolve these issues. The aim of the eduTEAMS service is to resolve these issues by providing a solution that is technically alike any other IdP in edUGAIN so the integration cost for SPs is reduced to zero, and offers multiple IdPs so the guest users may choose what they can / want to use.
This incubator topic aims to bring ORCID into the IDhub solution, with formal support from ORCID. It also investigates the (technical) improvements needed to better scale the IDhub solution and will begin a dialogue with the service activities to make the pilot move towards a full service offering under the GÉANT umbrella.
During the second sprint, the development team learned about the various technical aspects applying to eduGAIN and ORCID. A business case analysis was performed to identify requirements and opportunities as well as possible risks and issues when using ORCID as an IdP of last resort, especially from the perspective of the operator of such a service. The team continued discussions with ORCID representatives to figure out future ways to collaborate and to better understand the ORCID model of dealing with user consent. We will continue to investigate risks to the service operator, especially in regards to liability and GDPR. At the same time we will continue to develop a technical solution based on the SaToSa software stack.
Distributed vetting of Second Factor tokens
Several research communities, especially in the life sciences domain, have a need to use second factor authentication to improve the quality of their authentication. The GN4-2 eduTEAMS project conducted a pilot with the deployment of a Stepup Authentication Solution for the Life Science community. One of the challenges identified was how to securely vet the Second Factor tokens of the participants of a collaboration in a case where the members of the collaboration are very distributed, as is the case in most pan-EU research collaborations
This topic investigates, together with research communities, how the token registration can be scaled for scenarios where participants are distributed over the EU and beyond.
The initial aim of this task is to identify ways this vetting can be done. The team has engaged with this desk research by investigating recent literature and projects in and outside of the R&E community. Based on the results of this investigation an estimation will be made on the cost/effort of the methodologies and the improvement of the Level of Assurance that can be accomplished by the use of this methodology. Together with research communities we then want to identify the most useful ways of vetting the identities and create a test implementation for these flows.
In this activity is the following we completed a list of Interviewees we want to discuss our finding with. We also started work on identifing various functional building blocks that seem present in any token vetting process and build a model around that. Our current assumption is that using such a model we will be in a beter position to assess the various tools that are available. Our wokr continues to further test sme of teh flows we have identified, and we have begun with preparing a report of our findings. We expect to create and release some distinct proposals for distributed token registration and vetting, which will then be further discussed with research communities in one of our next sprints.
OIDC Shibboleth extension
Last but not least, work in the incubator is ongoing to introduce an OIDC (OpenID Connect) OP for the Shibboleth IdP. With such a component, an institution would be able to run a Shibboleth-based Identity Provider which would be capable to support both the SAML 2 protocol as well as the OIDC protocol for authentication on top of the same user directory.
Work will has continued to further improve the code, and response to user and developer feedback. In addition, work has been started to obtain formal OpenID Certification to prove conformance to OIDC profiles and interoperability.