This Wiki is available to view at but still under maintenance. PLEASE DO NOT EDIT THE WIKI UNTIL FURTHER NOTICE. We are attempting to restore missing edits which took place between Monday 8 and Thursday 11 April 2019, therefore the site is likely to be taken off line at any time. Updated 20:43 CEST 16 April 2019.
Page tree

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

EGI-DARIAH Interoperability Pilot

...

DARIAH is an ERIC, a pan-European infrastructure for arts and humanities scholars working with computational methods. It supports digital research as well as the teaching of digital research methods. It connects several hundreds of scholars and dozens of research facilities in currently 17 European countries, the DARIAH member countries. In addition, DARIAH has several cooperating partner institutions in countries not being a member of DARIAH, and strong ties to many research projects across Europe. People in DARIAH provide digital tools and share data as well as know-how. They organize learning opportunities for digital research methods, like workshops and summer schools, and offer training materials for Digital Humanities.

In AARC2, DARIAH is represented by DAASI International. The tasks of DAASI International in DARIAH include:

  • Constructing and operating an AAI (Authentication and Authorization Infrastructure).
  • Integrating new technologies like the management of virtual organisations via attribute aggregations.
  • Developing a long-lasting and comprehensive operating unit.
  • Conceptioning and developing the DARIAH storage infrastructure.

...

AAI_Logo.pngImage Added

Image Added

Pilot Description

This pilot consists of two individual parts:1.

  1. Implementation of an SP-IdP proxy within the DARIAH AAI. 
    According to the AARC Blueprint Architecture (BPA) communication between infrastructures should happen through dedicated infrastructure proxies. During this pilot, 
    DARIAH

...

  1. will implement their own proxy solution based on Shibboleth. This proxy will be compliant to all relevant recommendations and guidelines developed within AARC and therefore this pilot can be seen as a real

...

  1. world example of the architecture work within AARC. As as side effect DARIAH-internal services will benefit from this solution as well, as it will move a lot of the previously needed complexity away from the individual services to the central proxy component.

...

  1. Interoperability pilot between EGI and DARIAH
    To showcase successful implementation of the DARIAH SP-IdP proxy, the second part of this pilot deals with interoperability between the DARIAH research infrastructure and the EGI e-

...

  1. Infrastructure. The goal is to allow DARIAH users to transparently access EGI resources through EGI's own proxy solution (EGI

...

  1. Check-In). As an initial use case, selected DARIAH users should be able to deploy and access virtual machines in the EGI infrastructure.

The following (slightly simplified) diagram shows the interaction between the various components of the DARIAH AAI (green), home organisation IdPs (yellow) and EGI (red):

Image Removed

The central component, which is being implemented in this pilot, is the DARIAH SP-IdP proxy. The proxy implements the AARC BPA and serves as an AAI gateway for two scenarios:

  1. To allow users to authenticate at DARIAH services using their preferred authentication method (e.g. eduGAIN IdPs or the DARIAH homeless IdP).
  2. In the inter-infrastructure use-case the DARIAH proxy connect directly to the proxy of EGI (or other infrastructures in the future).

In both of these cases the user is assigned a DARIAH eduPersonUniqueId at the DARIAH proxy and the identity of the user is enriched with additional attributes (e.g. group memberships within DARIAH).

From a technical point of view the proxy is implemented using Shibboleth software. The Shibboleth IdP is the service-facing component of the proxy, while the Shibboleth SP deals with communication with the upstream IdPs. Since Shibboleth is not able to serve as a proxy out of the box, some additional glue is needed to connect the two components.

The other components involved are already being used in the current version of the DARIAH AAI (which is not using a central proxy) and have to be slightly modified to work with the proxy. This includes the DARIAH homeless IdP (Shibboleth IdP), the DARIAH group membership management and self-service portal (LUI) and the DARIAH services, which are mostly based on Shibboleth SP.

For the remainder of AARC2, the second use case (interoperability with EGI) will be completed as well.

3. Configuration instructions

You need admin privileges to perform the following:

Code Block
languagetext
titleAdd a pipeline
Select <collaboration> -> Configuration -> Pipelines -> Add Pipeline

See screenshot below for configuration settings

Image Removed

Code Block
languagetext
titleAdd Organisational Identity Source
Select <collaboration> -> Configuration -> Organisational Identity Sources -> Add Organisational Identity Source

See screenshots below for configuration settings

Image Removed

Image Removed

Code Block
languagetext
titleCreate RCAuth Enrollment Flow
Select <collaboration> -> Configuration -> Enrollment Flows -> Add Enrollment Flow

...

Image Removed

Image Removed

...

Code Block
languagetext
titleAdd and Configure VOMs Provisioning Plugin
Select <collaboration> -> Configuration ->  Provisioning Targets -> Add Provisioning Target

See screenshots below for configuration settings

Image Removed

Image Removed

Image Removed

Code Block
languagetext
titleCreate DARIAH Enrollment Flow
Select <collaboration> -> Configuration -> Enrollment Flows -> Add Enrollment Flow
Code Block
languagetext
titleConfigure DARIAH Enrollment Flow
linenumberstrue
<Name>, e.g. Confirm request for accessing EGI resources
<Status> => Active
<Petitioner Enrollment Authorization => Authenticated User
<Identity Matching> => None
<Email Confirmation Mode> => None
<Terms and Conditions Mode> => Explicit Consent
<Finalization Redirect URL> => The URL of the enrollment petition to follow. For this case the enrollment to follow is the RCAuth enrollment

See screenshots below for configuration settings

Image Removed

See screenshots below for co persons profile after finishing DARIAH Enrollment

Image Removed

Image Removed

Results

The first part of the pilot (Implementation of proxy within DARIAH AAI) was completed in mid-2018 with moving the new proxy component in the DARIAH AAI to production. We're successfully moved all DARIAH services behind the proxy and continue to add all new services to the proxy only. The feedback we got from service operations was positive and no major issues has come up. In addition we've promoted the enhances AAI experience with the proxy within the DARIAH community and held a workshop in January 2019 to assist new service operators with connecting their applications to federated AAI using the DARIAH proxy. Further events are planned.

For the second part of the pilot (interoperability with EGI) we've successfully completed the technical connection of the DARIAH AAI with the development instance of EGI check-in. This involves mapping of entitlements and user attributes and provisioning of DARIAH users within EGI. For the later tasks, several plugins for e.g. COmanage have been developed and successfully tested by EGI.

From DARIAH's point of view the technical infrastructure created during the pilot will be part of the core AAI in the future and will provide the basis for integration with other AAIs, e.g. as part of EOSC.

Others

The following diagram shows the interaction between various components in the EGI-DARIAH interoperability use case:

Image Added