GTS 1.3 Administrators Guide

[ GTS: Administrators Guide | Developers Guide | caGrid: Documentation Guides ]

Overview

The Globus Toolkitimplements support for security via its Grid Security Infrastructure (GSI). GSI utilizes X509 Identity Certificates for identifying and authenticating users. An X.509 certificate with its corresponding private key constitutes a unique credential or so-called "Grid credential" that is used to authenticate both users and services within the Grid. Under Globus, the authentication process ensures that the X.509 Identity provided by the peer was issued by a trusted certificate authority. However, one limiting issue with the current mechanisms is that trusted certificate authorities (CAs) and their CRLs are maintained locally on the file system of each Globus installation. When a client authenticates with a service, Globus locates the root CA and CRL of the client's Identity Certificate on the local file system. Once located, the Globus runtime validates the Identity Certificate against the CA certificate and CRLs. Although this approach is effective, it is difficult to provision CA certificates and CRLs in a large multi-institutional environment, as one has to ensure that all CA and CRL information must be copied to every installation and kept current with the dynamically changing environment. The GTS solves this problem by providing a Grid Service framework for creating, managing, and provisioning a federated Grid trust fabric. Through its service interface, the GTS provides the ability to register and manage certificate authorities. Using the GTS, Grid entities (services and clients) can discover the certificate authorities in the environment, decide whether or not to trust a certificate authority, and determine the levels of trust assigned to a certificate authority.

GTS Architecture

The figure illustrates how the GTS can be used to enable the Globus Toolkit to authenticate users against the latest trusted certificate authorities. To accomplish this, the GTS provides a framework called SyncGTS, which is embedded in the Globus runtime to automatically synchronize the local trust certificate store with the latest trust fabric maintained in the GTS.  When a Grid service is invoked, Globus authenticates the client by validating that the provided PKI credential is signed by a trusted certificate authority. The certificate is validated against a local store as illustrated by the figure. In the figure below, the Dorian certificate authority has been registered with the GTS as a trusted certificate authority and Globus has been configured to synchronize its local trusted certificate store with the GTS. For example, when an Ohio State University user invokes a Grid service using her Dorian-obtained PKI credential, Globus authenticates her.

Installation

There are two distinct installation scenarios for GTS.

• Installing a Master GTS
  When you are installing GTS for a new grid and the GTS instance will be the ultimate authority for which certificate authorities grid services should trust, you are installing GTS in the role of master GTS. The instructions for installing a master GTS are part of the caGrid Installation Guide.
  
  
• Installing a Slave GTS
  If you are installing a GTS instance that will get its information about which certificate authorities to trust from one or more other GTS instances then you are GTS in the role of slave GTS. Instructions for this type of installation are in the Slave GTS Installation Guide.

General

• Administrative UI
• Logging onto the Grid
• GTS Configuration
• Registration and Discovery

Management

• Trusted Certificate Authorities
• Levels of Assurance
• Trust Federation
• Administrators

Syncing With the Trust Fabric

• Overview
• Configuration
• Globus Runtime
• Command Line
• Programmatically