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?
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
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
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.
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:
- Component A - Service provider
- Component B - Bring order to chaos
- Component C - Hide my precious treasure
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 | 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 |
COmanage Modules configuration
You need admin privileges to perform the following:
Select <collaboration> -> Configuration -> Pipelines -> Add Pipeline
See screenshot below for configuration settings
Select <collaboration> -> Configuration -> Organisational Identity Sources -> Add Organisational Identity Source
See screenshots below for configuration settings
Select <collaboration> -> Configuration -> Enrollment Flows -> Add Enrollment Flow
See screenshots below for configuration settings
| Environment | Issuer 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}} |
Select <collaboration> -> Configuration -> Provisioning Targets -> Add Provisioning Target
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
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
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
(Here's a valid example LINK)
Allow DARIAH users to transparently access EGI resources through EGI's own proxy solution (EGI CheckIn)
Select <collaboration> -> Configuration -> Enrollment Flows -> Add 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
Demo 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:
Further information
Last part contain a list of information, link or anything related to the pilot that was not mentioned in ahead seciton.