After a start-up period where we bootstrapped the GÉANT Trust and Identity Incubator (see previous blog post), the Trust & Identity Incubator team has engaged with the first set of topics, resulting in the first sprint demo at the beginning of April.
In this post we present a (very) brief description of the topics and the results presented in this first Demo. A full version of the slides can be found at the April 5 sprint demo page.
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 first sprint we reviewed the requirements documents, identified 3 existing tools for managing entities (Jagger, Janus and OpenConext Manage), set up some infrastructure and started to deploy and evaluate these tools. As can be seen, we were not able to complete all tasks in the backlog, so it was decided to continue this work in the second sprint. The results of the evaluation will be presented in the upcoming sprint demo.
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 sprint demo, topic goals and (intermediate) results were presented (select to enlarge). A final version of the use case analysis is expected as part of the results of the next sprint.
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.
In the first sprint we worked on better understanding the existing platform, as we had to hand over from developers who are no longer in the project. We want to make sure we fully understand the current software stack and are able to deploy this. As part of this we started to reconcile the software into one public git repository. At the same time we learned an alternative product has been made available in Open Source, samlidp.io. We have decided to do a feature and architecture comparison between the two products. In regard to the business case evaluation, first steps were taken to create a canvas that will help evaluate and take into account scenarios, value creation, target users and provisioning model.
(select to enlarge)
Two videos were produced showcasing successful deployment of both products
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 sprint, the team set up a close collaboration with their counterparts from ORCID. During the sprint demo initial goals were showcased as well as a technical demo which showcases the principle works (select to enlarge / select to start demo)
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.
Initial work in this task started in two areas:
- Report document
- Secondary research: literature
- Primary research: Interviewees
- Requirements specification
- Use cases
Some possibilities identified to investigate:
- Physically at the door (postal)
- Live video chat
- Mobile app with picture of identity document and selfie / NFC technology for ID document
- Derived identity from strong authentication by iDIN, Idensys, or iDEAL; eID solutions via eIDAS;
- Central registration desk;
- Re-use of existing registration desks at other organisations like municipalities, banks, Chamber of Commerce, Certification Authorities or other education and research institutions; Community-based vetting, i.e. let other users do the vetting.
We noted that some of these methods not only allow token vetting but also improve user identification, which may or may not be beneficial. For our research, we need to take into account:
- MFA method vs Vetting Method
- Assurance level vs Vetting Method
- Re-use without contract
- User types, e.g. researchers
We expect to release our findings in a report in a later sprint.
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 protocol as well as the OIDC protocol for authentication on top of the same user directory.
This work was already started in GN4-2, and with support from and in close collaboration with the Shibboleth consortium, has recently released a 1.0.0 version of the extension. Work will continue 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.