Pilot Description
Main objective of this section is to provide a briefly high-level description of related pilot. The idea is to provide basic information, so that the reader can easily understand it.
Pilot goals
Some questions to answer:
What are the goals of this pilot?
Why is it in AARC project?
How this pilot will improve AARC community?
Why should I use this pilot instead of other solutions?
Description
Main objective of this section is to report detailed informations about pilot.
Some questions:
How this pilot works
Reason to prefer this pilot instead of other existing tool
Detailed Scope
others
Components
This section will contain a lists of components used for this pilot.
It is not required to add a detailed description for each component, but 3 important parts are:
- Add Link to component web page
- Add a short description to explain its function (not more than 1 raw)
- Explain why these components have been chosen
An example:
The pilot's goal is to first extend the existing DARIAH AAI with a SP-IDP-proxy according to the AARC BPA to allow for interoperability with other infrastructures, such as EGI. Afterwards this interoperability is proven by connecting the DARIAH proxy with EGI Check-In in order to allow DARIAH users access to EGI resources.
Pilot goals
The AARC2 pilot consists of two individual goals:
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.
Description
Introduction to DARIAH
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.
How the AARC BPA helped this pilot
The DARIAH research infrastructure offers the DARIAH AAI as one of the core technical services for researchers in arts and humanities. This enables researchers to log in to various services offered within DARIAH, by either using their own campus account or an account registered at the DARIAH homeless IDP. The DARIAH AAI adds information, such as group memberships specific to the DARIAH community or approval of general and optionally service specific terms of use, which can be used by services for authorisation decisions. Version 1 of the DARIAH AAI has been in production for multiple years and required every service to implement several details by themselves, e.g. connection to eduGAIN, attribute query to DARIAH for the additional attributes, validation of policy attributes and blocking and redirecting the user to the DARIAH self service portal if any of the information was missing or out of date.
In order to improve these limitations, be in line with the Blueprint Architecture (BPA) by AARC and therefore allow interoperability with other infrastructures, we decided to implement the DARIAH AAI version 2 as part of this pilot. In this version 2, which was created during this pilot, a central proxy component, which follows the proxy layer of the AARC BPA was added to complete the first goal (Implementation of an SP-IdP proxy within the DARIAH AAI) of the pilot. We were able to base the infrastructure on the building blocks of the BPA and also follow various guidelines from the AARC project on how to convey information to other infrastructures. Examples include the unique identifier or how to express group memberships in order to allow DARIAH users access to EGI resources.
Components
...
The components are as follows:
...
| Component | Description | Why did we choose it? | Link |
|---|---|---|---|
| RCAuth | Token Translation. Used to generate x509 certificates for access to legacy services | EU wide, sustainable infrastructure component | https://rcauth.eu |
| VOMS | Attribute Authority & Membership Management. | Pre-existing. Backwards compatibility | https://italiangrid.github.io/voms/ |
| EGI-Check-in | The second option for the proxy BPA-compliant proxy within EGI and membership management component | Implements multiple components, easier maintenance. Product used by other communities. | https://www.egi.eu/services/check-in/ |
| DARIAH Proxy | BPA-compliant SP-IDP-Proxy implemented within DARIAH AAI, based on Shibboleth IDP and SP | Interoperability with other Infras (e.g. EGI Check-In) | https://aaiproxy.de.dariah.eu/idp/ |
...
| shibboleth | |||
| DARIAH Group Management and User Registry | Management of internal DARIAH users and groups, as well as groups used for access to EGI resources | Access management to EGI resources is managed by DARIAH | https://auth.de.dariah.eu/cgi-bin/selfservice/ldapportal.pl |
EGI group management Modules configuration
You need admin privileges to perform the following:
...
See screenshots below for configuration settings
Architecture
This section will provide 2 important parts:
Graphic representations of pilot architecture
Graphic representations of workflow
Lists of all components of related pilot
AARC BPA version:
Use Cases
This section should explain how this pilot works through use cases (at least 2).
Use cases can be represented in the form of a table, where:
- The title is the use case
- Each line is a step
- 2 columns available, first with text and description, second with a screenshot
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:
- To allow users to authenticate at DARIAH services using their preferred authentication method (e.g. eduGAIN IdPs or the DARIAH homeless IdP).
- In the inter-infrastructure use-case the DARIAH proxy connect directly to the proxy of EGI (or other infrastructures in the future).
AARC BPA version:
Use Cases
...
Allow DARIAH users to transparently access EGI resources through EGI's own proxy solution (EGI CheckIn)
...
See screenshots below for co persons profile after finishing DARIAH Enrollment
Demo Videos Videos can be found here
- User accessing Dariah service
- Expunging a user from Group Management Framework removes the user from VOMS as well
Login flow from the PoV of a DARIAH User
A demo of the login experience for a DARIAH user can be found in these slides:
| View file | ||||
|---|---|---|---|---|
|
Further information
Results and sustainability plans
The implementation of the proxy was completed in mid-2018 and since then all DARIAH services have been moved behind the proxy. Since the architecture was designed with backwards compatibility in mind, the transition process did not create any major issues. Using the proxy to connect to federated AAI is now much simpler for service operators, hence we've already connected additional services to the DARIAH AAI and intend to continue doing so. For the second part of the pilot we've successfully finished connecting the DARIAH proxy with the development instance of EGI check-in. This includes attribute and entitlement mapping between DARIAH and EGI, as well as on the fly user provisioning within EGI. For this some plugins to the existing EGI check-in infrastructure were developed.
Within DARIAH the new proxy component is now part of the core AAI and will be operated as such in the future. The EGI Check-In framework also follows the AARC BPA philosophy and therefore will continue to be operated as part of the EGI organisation. This also included the enrollment workflows for DARIAH users. Last part contain a list of information, link or anything related to the pilot that was not mentioned in ahead seciton.