CILogon Pre-Pilot 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 retrieved credentials are then meant to be used as authentication in further interactions with grid services.

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

Use Cases

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 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.