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

Compare with Current View Page History

« Previous Version 9 Current »

DARIAH Pilot Description

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.

The AARC2 pilot consists of two individual parts:

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 implemented 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-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.

2. 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-infrastructure. The goal is to allow DARIAH users to transparently access EGI resources through EGI's own proxy solution (EGI CheckIn). 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):

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:

Add a pipeline
Select <collaboration> -> Configuration -> Pipelines -> Add Pipeline

See screenshot below for configuration settings

Add Organisational Identity Source
Select <collaboration> -> Configuration -> Organisational Identity Sources -> Add Organisational Identity Source


See screenshots below for configuration settings

Create RCAuth Enrollment Flow
Select <collaboration> -> Configuration -> Enrollment Flows -> Add Enrollment Flow


See screenshots below for configuration settings

EnvironmentIssuer DN
AARC pilot (e.g. LS AAI, WLCG){{/O=AARC/OU=AAI-Pilot/CN=AARC Simple Demo CA}}
Production{{/DC=eu/DC=rcauth/O=Certification Authorities/CN=Research and Collaboration Authentication Pilot G1 CA}}
Add and Configure VOMs Provisioning Plugin
Select <collaboration> -> Configuration ->  Provisioning Targets -> Add Provisioning Target

See screenshots below for configuration settings




Create DARIAH Enrollment Flow
Select <collaboration> -> Configuration -> Enrollment Flows -> Add Enrollment Flow
Configure DARIAH Enrollment Flow
<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


See screenshots below for co persons profile after finishing DARIAH Enrollment



  • No labels