Description of the SLCS

Content:

Introduction

We present here a description of the Short Lived Credential Service (SLCS). We first review the motivation for achieving interoperability between Shibboleth and grids in general and explain why the development of this short-lived credential service (SLCS) was chosen. Next we describe the software structure of the SLCS as well as  various deployment options, including the one chosen by SWITCH.

The SLCS service has been developped as part of the EU funded project Enabling Grids for E-ScienceE (EGEE) and the source code is available through the gLite software distribution (package org.glite.security.slcs). This description is an abbreviated version of the EGEE MRA1.4 document.


Motivation

Motivation for Interoperability between Shibboleth and Grid Infrastructures

The authentication of users in grid infrastructures is based on X.509 certificates, which are issued by certification authorities (CA). These CAs, mostly covering one country, form grid trust federations in order to allow users to access different grid infrastructures across different nations using only one X.509 certificate.

Recently novel mechanisms for inter-organisational authentication and authorization have been developed.  These authentication and authorization infrastructures (AAI), unlike those used in conventional grids, do not require users to have certificates.

The implementation of AAI in different countries took place independent of grid infrastructures. Often these AAIs were driven by national research and education networks (NREN) and are based on campus user databases. Examples of architectures that allow to implement such AAIs are Shibboleth (developed within the Internet2 project), A-Select (initiated by SURFnet), and PAPI (developed by RedIRIS). Shibboleth itself has attracted significant interest and has found the widest following with national installations in countries such as the USA, Switzerland, Finland, Australia and the UK. In addition, it is currently also under consideration in further European countries.

The following advantages can be gained by achieving interoperability between the grid infrastructures and these national AAIs:
  • A significant increase of the potential grid user base. Currently, grid users have to request a user certificate from a certification authority, which most have never heard of previously. With the inclusion of the national AAIs, and thus the campus user databases, it becomes straightforward for a user to obtain grid credentials.
  • X.509 certificates have turned out to be difficult for an average user to maintain. He/she has to understand the basics of asymmetric cryptography as well as various credential formats in order to use them in an efficient and secure manner.
  • The user has one credential less to maintain. 
  • The user can access the grid using his/her campus credential, with which he/she already accesses many resources.

Motivation for Interoperability through a Short Lived Credential Service (SLCS)

Shibboleth is based on the exchange of digitally signed assertions about users, expressed in a language called the “security assertion markup language [SAML]. These assertions are exchanged between an Identity Provider and a Service Provider. The role of the Identity Provider is to authenticate the user and administer the information about the user. The Service Provider is the resource that the user wants to access. The following links provide a detailed description of Shibboleth and SWITCHaai, the Swiss Shibboleth federation.

Because of the pervasive use of X.509 certificates in grid middleware a replacement of X.509 credentials by SAML statements is neither desirable nor practical. Therefore it was decided to issue a short-lived X.509 credential to a user based on his/her successful authentication to a Shibboleth Identity Provider. The user requests these certificates by executing a shell command on the machine from where he/she wants to submit jobs to the grid (see figure below).



The advantages of this approach are:
  • The X.509 credential becomes less visible to the user as it is generated upon authentication to the Identity Provider (which the user already frequently uses for authentication purposes).
  • The X.509 certificate “disappears” from the user’s point of view after it has expired.  He/she thus does not have to retain it over a longer period of time. 
  • The addition of new software to the middleware is limited to the host used by the user to submit jobs to the grid. In gLite this is the UI component. 
  • Only one additional service (per Shibboleth federation) has to be developed and deployed. This service is called SLCS and its implementation within the Swiss AAI federation is called SWITCHslcs.
As described above, the distinct advantage of the SLCS is to enable access to the grid infrastructure for Shibboleth users with a minimal amount of effort. However, several caveats should be mentioned as well. First this effort leaves the basic X.509 based grid security infrastructure in place and does not fully exploit the benefits of SAML. Second, the user’s attributes that are being maintained by the Identity Provider of the user are not available to any grid resources. Thus this work is a very useful first step for achieving interoperability between Shibboleth and grid infrastructures, but its scope is limited.



Implementation of the SLCS

The User's View of the SLCS

From the user’s point of view, he/she executes a shell command on the host, from which he wants to access grid resources (we call this host UI in accordance with the gLite terminology).  In return he/she obtains a short-lived certificate (in PEM format) in the $HOME/.globus directory.

The usage of the shell command is described in detail in here. The user has to supply as command line arguments the name of the Identity Provider and optionally the user name (if different than username on the UI host). The slcs-init command then demands that the user enters his Shibboleth password and a passphrase for the private key that is being generated.

A command line command exists which lists all Identity Providers that are known to the UI.

The user does not have to do any configuration by himself, which is done by the UI administrator.

Shibboleth Administrator's View of the SLCS

There are two tasks that the administrator has to do:
  1. Installation and configuration SLCS client on the UI
  2. Installation of the SLCS server and (possibly) backend CA
The installation  and configuration of the SLCS client is done by the UI administrator, who has to ensure that
  • a federation specific configuration file contains all Identity Providers of the federation and
  • the server certificates of the Shibboleth Identity Provider and SLCS server are known by the user agent if they are not certificates supported by default in generally available browsers.
The federation specific configuration file must be configured on a federation basis. However, several Identity Providers from different federations can be listed in the same configuration file but currently only one SLCS server.

The SLCS server is – from the Shibboleth administrator’s point of view - a Shibboleth Service Provider that has to be set up on a dedicated host and has to be added to the federation’s metadata. There is one SLCS per Shibboleth federation.
The setup and administration of the SLCS is described in detail in in the SLCS administrator manual.


Software Design

The following steps take place when a user requests a new short-lived certificate from the SLCS (see Figure below):

  1. The user executes the shell command to request a new short-lived certificate. This spawns a user agent, which tries to access the SLCS in order to request a certificate.
  2. The SLCS redirects the user agent to the Shibboleth Identity Provider, where the user is authenticated based on his username and password. 
  3. The Identity Provider issues a handle to the SLCS Service Provider through the Shibboleth Browser POST profile [R6]. 
  4. With the handle the SLCS Service Provider retrieves the SAML attributes of the user and generates a certificate subject derived from the user’s attributes. 
  5. The user agent receives his certificate subject name and an authorizing token as an XML message. He generates locally a private key and a Certificate Signing Request (CSR). 
  6. The user agent sends the generated CSR and authorizing token back to the SLCS Service Provider. 
  7. The SLCS receives the CSR and verifies it. A PKCS#10 is sent to the Online CA for signing. 
  8. The Online CA automatically signs the PKCS#10 and sends a short-lived certificate (PKCS#7) back to the SLCS server. 
  9. The SLCS server sends the signed short-lived certificate back to the UI as an XML message. The audit log is updated. 
  10. The user's certificate is stored on the UI.


Software Implementation

The software implementation is structured in three functional blocks:
  1. The SLCS front-end consisting of an Apache server and Shibboleth Service Provider.
  2. The SLCS server, which is a Java servlet running under the Tomcat servlet engine. 
  3. An online CA, which signs the PKCS#10 requests.

Note that these three functional blocks are normally (but not necessarily) installed on separate hosts. Standard software interfaces are used between these components (mod_jk between Apache and Tomcat and the CMC protocol between Tomcat and the online CA). Further details are given in the section on deployment options.

The Figure below shows an overview of the software components, on which we briefly comment on some key features.


  • There are three servlets within the SLCS:
    • The login servlet controls the login of the user, builds the string Distinguished Name (DN) of the certificate and manages the user sessions. 
    • The certificate servlet receives the CSR from the user agent, checks that it is consistent with the policy and communicates with the online CA through a CA client module. 
    • The administrator servlet  allows an administrator to log in to the SLCS, view the log and add or remove accepted users from an access control list.
  • Java Filters control the access to these servlets (ACL filters in the figure above) 
  • The communication between the servlets and the underlying codes takes place exclusively through standard Java interfaces. The classes implementing these interfaces are loaded at start-up based on entries in a configurable XML file. This mechanism allows easy replacement of existing components. For example if the DN needs to be constructed according to different rule. In this case a new class implementing the DN Builder interface must be written and its name added to the SLCS XML configuration file. 
  • The CA client interface is responsible for the connection to the online CA. The current distribution contains a class CMC Client, which implements the RFC 2797 protocol. 

Deployment Issues

Two components must be deployed in order to make the SLCS service available to grid users:
  1. UI client component
  2. SLCS server component
We describe in this section the different deployment scenarios for these two components.

UI Client Component

The user interacts directly with the UI client component by invoking it through the command line. There are two possibilities for deploying the UI client component:
  1. Through the gLite distribution: In this case the UI system administrator downloads an .rpm file from the official gLite repository and installs it through the standard gLite installation procedures. This is the recommended way for installing the UI client in a standard gLite installation.
  2. By installing a .tar.gz file: In this case the UI system administrators installs a .tar.gz file containing all the Java classes and libraries of the UI client component into a well known directory and adjusts the classpath correspondingly. This is the recommended way to install in the UI client in a non-gLite or standalone environment.

SLCS Server Deployment

Several fundamentally different options exist for the SLCS deployment and the following list of questions should be answered before deployment is started:
  1. In which Shibboleth federation should the SLCS service be added and is its addition to the federation compliant with the policy of the federation?
  2. Shall the service be accredited by the IGTF (resp. EUGRIDPMA) or not?
  3. How shall the service be operated within the federation?
The SWITCHslcs service operates as a SWITCHaai federation wide service and has been accredited by the IGTF.