CILogon Pre-Pilot Work

NOTE! This page might NOT be what you're looking for! Some of the information previously stored in this page has moved into its own dedicated page, because this page was getting to large! Please look at out landing page to find newer and updated information on the AARC Piloting work!

Introduction

AARC is a European research and collaboration project which explores the possible future generation of authentication and authorization methods used in the grid world. CILogon is a candidate AAI component within this project. This document is the starting point of a piloting work on CILogon which will eventually evolve into a larger scale demonstration of the capabilities of this software product.

CILogon is an open source project used to provide x509 certificates based on the authenticated user's federated identity. These x509 certificates are then meant to be used as authentication in further interactions with grid services.

For high-level information, we refer you to:

• Digital certificates behind the scenes: the AARC CILogon pilot
• RCauth.eu and the CILogon-like TTS Pilot in Europe
• Sustainability models for the CILogon-like TTS pilot and the status of the RCauth.eu white-label service by Nikhef
• Pilot ongoing status

Technical pilot development

Phase I

We used Jenkins together with OpenStack to build an automatically deploying demo instance. Jenkins VM Image templates are used to boot VMs with relevant software installed on it, while separate Jenkins jobs are used to carry out different stages of the service deployment. You can find more details at CILogon Pre-Pilot Work - Jenkins and github.

Phase II

After our experience with Jenkins from Phase I we decided to use try a more suitable system for deployment and configuration management. We wrote a set of Ansible scripts for both Master Portal and Delegation Server used in the RCAuth.eu setup. Execute these deployment scripts following the guide.

In case you are looking for a guide to build either Master Portal or Delegation Server, check out our building from source guide.

Pre - Piloting with OA4MP

Demonstration Portal

We aimed our first use case at setting up a Demonstration Portal through which authenticated users can retrieve x509 certificates. This setup mimics the CILogon Portal Demonstration.

The user goes to the Demonstration Portal and starts the flow by asking for a certificate. The Demonstration Portal creates a new private key and a certificate signing request (CSR). The private key is kept in the Portal, while CSR is eventually sent to the Delegation Service (acting as an online CA). At the Delegation Service the user gets redirected to his home IdP for authentication (for now there is only one single IdP in our setup). After authentication and consent the user attributes are sent to the Delegation Service. The Delegation Service uses MyProxy-Server (CA) to create a user certificate from the CSR and user attributes. This certificate is then sent back to the user.

Components

CILogon is based on OAuth for MyProxy (OA4MP). For the purpose of this Demonstration Portal we used OA4MP because it's much better documented then setting up CILogon itself, and because it was the recommended way to go by Jim Basney (CILogon).

• OA4MP : using both the client and the server components from the latest OAuth 2.0 implementation (3.1.1)
• Shibboleth : using the latest Identity Provider (3.0), and Service Provider (2.0)
• MyProxy Server : using official releases from epel (6.1.13)
• SimpleCA : using official release from epel (4.20)

Architecture

Demonstration Portal

- The Portal runs as the oa4mp-client (oauth2 client) in this setup. The protected resource in this case is the user certificate that will end up in the Portal at the end of the oauth2 flow. This Portal is then used to access a protected resource with the user certificate as suggested by [1] (this is not part of our demo setup just yet).

- The oa4mp-client has to be registered with the corresponding oa4mp-server before it can be used. This is usually done through the /register endpoint of oa4mp-server.

Delegation Service / SP

- The Delegation Service runs as the oa4mp-server (oauth2 server) and provides a frontend to the MyProxy CA. The oauth2 protocol implementation follows the specifications outlined at OpenID Connect for MyProxy.

- The oa4mp-server runs behind an httpd reverse proxy configured with mod_shib, which redirects requests to Shibboleth IdP for user authentication.

Shibboleth IdP

- This is a simple Shibboleth IdP setup backed up by an LDAP server. It releases user attributed to the Shibboleth SP running in front of the Delegation Service.

MyProxy Server / SimpleCA

- MyProxy Server is configured to run as Certificate Authority (CA). It creates user certificates from the CSR and user attributes. The user attributes are used to fill in the certificate subject with the aid of myproxy-certificate-mapapp.

- SimpleCA is used to create the initial root CA certificate.

Sequence Diagram

The following sequence diagram details the flow of the delegation scenario described above. The user in this diagram stands for the users' browser which is redirecting calls. It contains the OAuth2 calls also outlined in the OpenID Connect for MyProxy specifications, and the SAML calls describing the interaction with the IdP.

Note: There are two separate consent pages displayed during the above interaction: one from the Shibboleth IdP and one from the OA4MP Server. The reason for this is mainly because this is only a test setup. In a production environment this might be replaced by one single consent page.

Other Resources

Demo Portal

There is a variant of the Demonstration Portal run by CILogon at [2]. This is an alternative OA4MP Client implementation which can replace the Demonstration Portal described above. It is, however, functionally equivalent to the OA4MP Client with a CSS facelift.

CA security

CILogon uses SafeNet Luna hardware security module to protect their CAs. Details and sources of this setup can be found at [3] and [4]

MyProxy Server Frontend

It is also possible for the CILogon users to retrieve a p12 certificate through their browser from a frontend service [5]. This is simply a php frontend for MyProxy Server which does not utilise the oauth2 flow. Sources for this component can be found at [6].

Using a MyProxy CA setup for generating 'Per-User Sub-Proxies'

It is possible to reconfigure a MyProxy server (running in CA mode) to produce proxy certificates from an End-Entity certificate. This can be used to create so-called 'Per-User Sub-Proxies' (PUSPs). This is described on a dedicated wiki page. Such an 'online CA' can be used in a transitional phase instead of a proper online CA.