Introduction: certificates 101
In a digital world, we also need digital identities. Everyone nowadays has a Google, Facebook, etc. account and is used to logging in using a username (email address) and password. This works great for end users who want to do all their work via their web browser and who are constantly around. On the other hand, in the scientific world, researchers like to start work flows and come back much later when the work is finished. For these latter type of jobs, in the early days of the Grid, people have come up with a system where every user gets a personal digital certificate (a X.509 End-Entity Certificate to be precise, such a certificate is very much like the certificates used in https by web-services to prove who they really are).
These personal certificates are like a digital passport, containing information which uniquely identifies the individual, and which has been digitally asserted by a so-called trusted certification authority (CA), very much like a ‘real’ passport is asserted by a government.
Which CAs are trusted by a certain eResearch community, is decided by the Interoperable Global Trust Federation (IGTF). Apart from establishing the set of approved CAs, this international body also determines the policies they have to abide by.
In order to do actual work, researchers typically work together across organizations and countries, and people started to form so-called Virtual Organizations (VO) to deal with this.
Researchers register with a VO showing their digital certificate; the VO will then hand out a derived certificate, which contains the specific roles and groups the user belongs to, very much like a club membership card. These latter certificates are typically short-lived, tightly bound to the end-entity certificate and are called proxy certificates (Standardized in RFC3820).
The membership and the role researchers have in the VOs determines which resources they are allowed to access.
Federated access to certificates
All this infrastructure works very well for experts who are used to handling certificates and private keys, but is conceived as very difficult by most end-users. We have seen people leave their private keys in internet cafés, on deleted virtual machines, in the wrong browser etc. On the other hand, for automated systems, certificate-based authentication is fast, reliable, well-supported, well-understood from a security point-of-view etc. In the ideal digital world we therefore would like to use these certificates under the hood, while the end-user uses a ‘simple’ username/password based institutional or perhaps even Google- or Facebook login to authenticate.
There have been a few steps made in recent years to make this happen. In Europe we have seen the (formerly Terena) Trusted Certificate Service, TCS, which eases the way of obtaining a certificate, but still leaves the burden of handling the certificate and key with the end user. At roughly the same time, in the US, the CILogon project started a more advanced online service for producing certificates, which not only allows users to download a certificate based on a institutional login, but also provides a way to delegate the certificate to a third party, e.g. a web portal of an e-infra provider.
This portal-delegation scenario is ideally suited for our work-flow use-case described above.
AARC CILogon pilot
Within AARC we decided to try to pilot the existing CILogon software, adding some glue here and there and to see whether we can create a workable scenario for the European research and e-Infrastructures: The end-users do all their work via a web portal where they login with their institutional credentials. When needed, the web-portal can use a personal (proxy-)certificate for the end-user to do the actual work-flows, but the end-user will not see the certificate.
There have been other efforts, to build software solutions around such an online CA. For example EUDAT has a scenario, where the user’s username/password login can be ‘translated’ into a X.509 credential when needed, but their CA is only used and accepted within EUDAT itself, it is not an IGTF accredited CA. Depending on the outcome of our CILogon pilot, a further pilot to look at the EUDAT software might be considered. A second motivation for trying the CILogon software first is its modular design, the CA is a more or less standalone and easily adaptable component.
One might also wonder why we did not just reuse the US CILogon instance, or at least its already IGTF approved and accredited CA. The primary reason for this is the difference in handling personal information: by design the online CA needs to handle quite a few user attributes, and it would be very difficult to get European institutes to accept releasing attributes to such a service based in the US.
AARC pilot implementation
In the first year of AARC, as part of the SA1 work package, we have been working hard and have built a working Proof-of-Concept, including a backend online CA.
Our setup falls apart in roughly three separate parts (see Fig. 1 below):
- a central online CA with a web frontend (yellow parts),
- a caching and credential handling Master Portal (red parts),
- Science gateways run by VOs (VO portals) (blue parts).
The end-user interacts almost exclusively with the VO portals.
The Master Portal is a new component, based on a replication of the CILogon software, in order to move all the complexity away from the VO-run science gateways. The net result is that it is extremely easy for the VO portals to securely obtain credentials, based on the OpenID Connect protocol (acting as a client). The Master Portal takes care of obtaining the longer-lived end-entity certificates, caching them in the form of a proxy certificates and handling the additions of the VO-based attributes. Due to the more modular setup, having this extra component in the middle also makes it easier to reuse the same online CA for different e-Infrastructures.
In collaboration with AARC-Policy Work Package (NA3), we have built an online CA following all the necessary policies for such CAs. This CA has just been approved for accreditation by the IGTF, paving the way for adoption in the real world. Building a fully-compliant online CA turned out to be one of the more complex parts of this pilot. Ultimately this CA should be run by one of the bigger players involved, on a pan-European scale, accessible and usable by the entire European research community.
We have successfully set up Proof-of-Concept pilots with both ELIXIR and EGI, where these infrastructures each run copies of the Master Portal. The basic workflow has been proven and it is foreseen that these pilots will go into a next phase in the coming year, in which we will finalize the CA and the Master Portal software.
We hope that this work will enable many more researchers to use the available infrastructures fully to their potential without having to deal with the complexities of the underlying certificates.
Further reading:
