To enable federated access to shared resources of research communities and to enable the integrated use e-infrastructure services, the pilots activity in AARC will run a large number of pilots as a step-up to concrete AAI services. The requirements of research communities and e-infrastructures will drive the design of either missing AAI components or new services. To put this into action the AARC pilots activity consists of 4 tasks:
Table of Contents
Below you find a more detailed description of the activities to be performed for each task
Task1: Pilots with research communities based on use cases provided (lead by GARR and GRNET)
A total of eight use-cases from research communities have been selected to pilot with AAI solutions. A support team will be created to work with the research communities to match the best solutions and architecture with those use cases. Intermediate results will be shared with the relevant communities and feedback will be used to advance the further work.
| Community | Links | Topics/Focus | Status | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Connecting services & Brokering Leverage the work done by AARC on policies and architectural blueprints Implementing Sirtfi Using eduGAIN |
| |||||||||
| Move away from IP based access towards federated AAI according to the AARC BPA |
| |||||||||
| Evolve current AAI towards one that is fully compliant with AARC BPA; support cross infra use cases with EGI/EUDAT/PRACE and delegated federated access (non-interactive) workflows |
| |||||||||
| Initial implementation of Community IdP/SP proxy, Group/Role based access to resources, SIRTFI and CoCo/GDPR compliance |
| |||||||||
| Implementation of AAI according to the AARC BPA; access for citizen scientists |
| |||||||||
| Inter compatibility, share a common AAI shaping according to the ideas in Elixir. Also focus on sustainability and operational aspects
|
| |||||||||
| Implementation of IdP/SP Proxy, mainly to provide Token Translation Services to allow end users to login without the need of manually managing X.509 certificates |
| |||||||||
| Implement AAI according to AARC BPA |
| |||||||||
| DARIAH AAI | Implementing an AAI according BPA to allow communication between DARIAH and other infrastructures |
|
Task2: Support and pilots for e-infrastructures interoperability and integration (lead by EGI)
This task will focus on piloting AAI components and frameworks to enable transparent interoperability between infrastructures in terms of authentication and authorisation and will build on the state of the art of the AAI services provided by the infrastructures.
This task’s work will be driven by the requirements and use cases of both e-infrastructures and research infrastructures and the results of the JRA1 activity.
| e-Infrastructure | Links | Topics/Focus | Status | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| EUDAT-EGI pilot for cross-infrastructure access to resources | The technical integration of the EGI and EUDAT AAIs has started but we recognize that additional effort is needed to harmonise attributes and Level of Assurance (LoA) definitions. The team therefore continues to work on an earlier started joint proposal by AARC, EGI and EUDAT to harmonise the LoA of their identities for consumption by their internal services. | This pilot has been absorbed by the LS AAI pilot | ||||||||
| EUDAT-PRACE pilot for cross-infrastructure access to resources | The high-level goal of this pilot is to achieve AAI interoperability between EUDAT and PRACE and to examine how Unity technology may be used to accomplish this task. The solution consists of two components. The first one is the automatic provisioning of accounts for selected PRACE users who authenticate with x.509 certificates. EUDAT accepts these certificates and PRACE users become registered users in the EUDAT authentication and authorisation service. This gives PRACE users access to non-x.509-based EUDAT services. The second component needs to synchronise these accounts with EUDAT data services using certificate credentials. |
| ||||||||
| DARIAH AAI | Implementing a Proxy-Element according to the AARC BPA in the DARIAH AAI and enabling integration with EGI There are two consecutive and related pilots:
|
| ||||||||
| Two pilots:
| This pilot has been absorbed by the LS AAI pilot |
Task3: Piloting advanced use cases, new solutions and approaches based on the outcomes of JRA1 and NA3 (Lead by GRNET)
This task will pilot solutions that complement the eight AAI use cases provided by the selected research communities (piloted within Task 1) and the cross e-infrastructure integration issues addressed by Task 2. As such, the task will investigate advanced AAI scenarios by taking into consideration the results of AARC1 and by building a feedback loop with JRA1 and NA3.
These advanced scenarios include scalable and highly available authorisation schemes in multi-SP environments. In addition, emerging and new technologies (e.g. OpenID Connect for establishing federations, beyond password solutions, integration approaches for multi-protocol cross-sector identity federations) will be assessed and piloted in this task to confirm their feasibility in real-life scenarios.
In addition, this task will deal with cross community use cases. In Q4 2017, Task3 started the Life Sciences & Health pilot for the CORBEL community. This was triggered by a formal request by CORBEL to come up with an overarching AAI infrastructure. Since AAI is not the 'core business' of CORBEL, they prefer having that part sustained by the e-Infrastructures. Therefore, CORBEL wrote a document with their AAI requirements (See: https://goo.gl/zvTQmB) and requested the 3 e-Infrastructures in AARC2 (EGI, EUDAT & GÉANT) to respond with a proposal. It quickly became clear that the best way to approach this respons was to submit a combined proposal, where each e-Infrastructure provides a part of the final solution. A first phase of a pilot has been finalised early February. A recording of the demo is available here: https://geant.app.box.com/v/ls-aai-phase-1-demo. The second phase of the life science pilot commenced in February, results will follow soon.
Task4: Creation of showcases, deployment scenarios and documentation based on successful pilots in AARC2 (Lead by RETI)
The pilots in AARC and AARC2 will produce a lot of experience, documentation and interesting showcases. In collaboration with the NA2 activity, these results will be combined with technical training material and offered as one package to the community.
This material in combination with the relevant sustainability plans, will be fed to the Competence Centre to ensure that a home for the results is found. The results for this SA will be rooted via the for federating communities forum. AARC2 showcases will be used to demonstrate how the proposed AARC blueprint architecture will help simplify the daily work for researchers collaborating in several different communities and using different infrastructures.
Previous results of the pilot activity in the first edition of the AARC project (first edition of AARC 2015-2017) which ended in May 2017, are available here.
Overall goals and approach of SA1
Work Package Leader: SURFnet, user-e06a9
The SA1 activity aims at facilitating researchers by providing the access management tools and framework to support collaborative research in a distributed environment. To this end, in SA1 we will demonstrate through (pre-) production services that:
existing AAIs and authentication sources can be leveraged to enable (SSO) access with appropriate level of assurance for any natural person (academia and non-academia) to shared resources offered by different e-Infrastructure providers and communities. (task 1)
authoritative decisions and user/group context can be based on distributed group managers and attribute providers. (task 2)
access to non-web and commercial e-infrastructure services can be enabled. This requires the bridging of SAML (NREN world) and token/certificate based (e-infra world). (task 3)
The approach consists of deploying existing components as discussed with and identified by JRA1 and to integrate a selection of these components according to a common architecture that will be drafted in JRA1 as well (by October). To this purpose we will establish a stable pilot environment with solutions to be tried and assessed by representatives of the research communities affiliated with the project.
...
Guest Access (TSA1.1)
...
Task Leader: GARR, Mario Reale
This task deals with the pilot activities to be set up for AARC in the domain of Guest Identities; It will mostly liaise with JRA1 and NA3 of AARC in order to effectively demonstrate the validity of the selected components and architecture designed in JRA1 and the best practices and recommendations identified in NA3.
see this link for a more detailed description of this task
Attribute Management (TSA1.2)
Task Leader: EGI, Peter Solagna
...
This task deals with piloting of solutions to manage attributes on a central and cross application level. An integrated framework of identity providers, attribute and group providers, attribute aggregation platforms and shared e-infrastructure services that are able to consume attributes will be demonstrated and tested.
...
see this link for a more detailed description and preliminary work that has been undertaken for this task
Access to resources (TSA1.3)
Task Leader: PSNC Maciej Brzeźniak
This task aims at improving access to relevant research and education non-web resources located outside the home organization of the user. The main improvement is making use of existing AAI that provide user credentials and authorization attributes instead of local user management. While many implementations exist already for web portals, the technology for non-web scenarios is still immature.
...
A number of pilots is going to be setup in order to investigate emerging non web SSO solutions and workarounds. The selection of software to be piloted is going to be discussed with JRA1 in order to focus on tools that fit with the requirements of the research community and the blueprint architecture (JRA1.3 and JRA1.4). Also the requirements gathered by JRA1.1. will be used as input material for the assessment of technologies used in the pilots. Finally, the experience gathered while running the pilots and the performed analyses will be used as feedback for the final shaping of the blueprint architecture in JRA1 and best practices recommendations in NA3.
...
Compatibility between the technologies piloted within this task and technologies used for collecting attributes within task SA1.2 will be checked. Attribute requirements for non-web SSO, authorization and provisioning will be investigated and defined. Usage of user credentials and attributes coming from different AAIs, including guest IdPs proposed by SA1.1 will be analyzed as well.
...