You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 19 Next »

Participants

Proposers
NameOrganisation
SURFnet
GN4-3 project team
NameOrganisationRole
SURFnetP.I.
DFN-LRZScrum master

Mihály Héder

KIFUMember
RASHDev
Vangjel StavroRASHDev
GEANT AssociationMentor
Stakeholders
Name

Organisation

Role 
Laura Paglione on behalf of ORCIDORCID ORCID contact person
Christos KanellopoulosGEANT AssociationeduTEAMS Service Owner

Activity Overview

Description

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 trough external identity providers like social ones. This has lead to serious reinventing of the 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 centralized service could be offered to resolve these issues. This resulted in solution named IDhub that uses SaToSa product. The aim of this solution was to resolve these issues by providing technically alike any other IdP in eduGAIN so the integration cost is reduced to zero, and offer multiple IdPs so the guest users may choose what they want/can to use.

This pilot aims to bring ORCID into the IDhub (SaToSa) solution. It investigates the (technical) improvements needed to IDhub. At the same time it will investigate the requirements to be able to offer such a service with formal support from ORCID. 

Goals
  • Implement the ORCID member API into IDhub (SaToSa)
  • Identify requirements and issues that would prevent GEANT from operating this as a service

Activity Details

Technical details
Technically this is an application of SaToSa where the south side is a SAML IdP exposed to GEANT or other SAML federations the north side is ORCID API, which is based on OAuth.
Business case
It is assumed this service can be maintained at low cost and enhances the appeal of eduTEAMS and eduGAIN, and at the same time it creates a good relationship with ORCID.


Data protection & Privacy
Users personal data will be processed when the data will be handled from ORCID into the SAML side, therefore a data protection policy about how this data is handled needs to be defined.


Definition of Done (DoD)

The project is finished when:

  • ORCID API can be used for authentication in the IDhub (SaToSa)
  • requirements and issues have been identified that would prevent GEANT project form offering such an IdP into eduGAIN


Sustainability
The intent is to initially offer this as part of eduTEAMS

Activity Results

Results
Please provide pointers to completed and intermediary results of this activity

Meetings

Date

Activity

Owner

Minutes

February 19, 2019

Kickoff meeting


 ORCID kick off.pdf
















Documents

No files shared here yet.

ORCID IdP as a Last Resource Business Case Analysis


  • No labels