AARC’s CILogon pilot helps users to use resources from different infrastructures

AARC’s CILogon pilot helps users to use resources from different infrastructures

This blog is part of a mini-series reflecting on how AARC has worked together with different e-infrastructure and research infrastructure projects to help them to adopt federated access and deliver services in a more user-friendly way. The first in the series was published in October 2016: https://aarc-community.org/a-hitchhikers-guides-to-the-aai-galaxy/ .

In this post we report on the AARC pilot to evaluate if whether the ELIXIR and EGI infrastructures can be seamlessly connected, so users can access EGI resources with their ELIXIR identity.

Users from one research infrastructure can easily and securely use services from other research infrastructures

The goal of research infrastructures is to help researchers to do their job. This, from the IT point of view, usually means providing a set of services for storage, content management, indexing and computing. If the services contain sensitive data or they just need to do accounting, then proper authentication and authorisation (AA) of the users must be in place.

ELIXIR is a research infrastructure oriented towards life sciences, where researchers among other things need to do large-scale computations. For those computations they need enough resources. It makes sense to use resources from other infrastructures that are oriented towards building distributed computational and storage capacities, such as EGI. The AARC pilot assessed whether the ELIXIR and EGI infrastructures could be seamlessly connected in a way that:

  • enables EGI to identify ELIXIR users (meaning users authenticated via ELIXIR AAI);
  • allows only approved users to access EGI resources (authorisation done by ELIXIR based on agreement between EGI and ELIXIR)
  • keeps the process user-friendly.

The solution

As a technical solution, we chose the CILogon-based AARC pilot, which resulted in the rollout of the RCauth.eu online certification authority (CA) (see this blog post) that underlies the CILogon-based pilot. Because this CA is IGTF accredited,  EGI is able to accept its certificates. To enable ELIXIR users to get certificates from the RCAuth.eu CA we needed to deploy an extra service, a so-called master portal. We successfully deployed this service with a MyProxy backend component in ELIXIR and connected it to the RCauth.eu CA. This was not enough though: having just a certificate would not yet allow ELIXIR users to use EGI resources. For that, ELIXIR needed a dedicated virtual organisation (VO) defined within EGI, which technically represents ELIXIR users in EGI.

The certificate issued by the RCauth.eu must be extended by so-called VOMS extensions that contain the user’s affiliation with the VO, which, in the case of ELIXIR users is vo.elixir-europe.org. Technically it means ELIXIR must propagate information to the VOMS service about the users who are allowed to use EGI resources. We set up a provisioning procedure from the ELIXIR AAI using Perun system (see this Perun VOMS CILogon pilot description) to the VOMS server managed by the EGI infrastructure.

Because not all ELIXIR users can access EGI resources, we created a group that is managed by ELIXIR representatives. Information about a user’s group membership is transferred to the RCauth CA every time the user requests a certificate from it. Group membership data are also pushed directly into the VOMS service, therefore the master portal has them available when it requests VOMS extensions to be added into the newly created certificate. If the ELIXIR user is not in the proper group, the master portal will refuse the request.

The user’s view

From the user point of view, the flow is as follows:

  1. The user requests membership for a group: vo.elixir-europe.org.
  2. If the request is approved the user is notified and from now he/she can request certificates from RCauth.eu or directly access services using EGI resources.
  3. The user can access e.g. the cloud management portal, which allows the user to start the virtual machines on the EGI fedcloud infrastructure.
  4. Before the user gets into the cloud management portal he/she is requested to authorise towards the RCauth.eu CA using his/her ELIXIR ID. This is the only place where the user interacts with the CA: he/she is asked to consent to data release from ELIXIR to RCauth.eu and subsequently from RCauth.eu to the ELIXIR master portal.
  5. After that the user is redirected back to the cloud management portal with the token from RCAuth.eu, which is used by the portal to get the user’s certificate from RCAuth.eu. The portal can then use the user’s certificate to call EGI services on behalf of the user. EGI services now recognise the user even without any direct registration with the EGI infrastructure.

Real-life uses

The pilot was successfully demonstrated on this above mentioned use case. The pilot described demonstrated that users from one research infrastructure can use services from other research infrastructures in an easy and secured way. All the difficulties are hidden behind the scenes, therefore users do not need to do another registration and services can rely on approved identities even if they use different  authentication  protocols.

Users from ELIXIR are also using certificates from RCauth.eu for gridftp transfers; they just use a simple application which generates the proxy certificate and shows it in a browser. Users can store that certificate locally on their machine and initiate gridftp transfer. Another use case with RCauth.eu certificates is use of GlobusOnline service. The huge benefit here is that users  are still able to use their ELIXIR ID, which, in turn, leverages the user’s federated identity.

This is a further example on how RCAuth certificates are used for real life use-cases and how it makes it easier to share services among research infrastructures; this saves operational costs and makes more efficient use of services.

Skip to content