# GlideinWMS The Glidein-based Workflow Management System

- Home
- Download
- Glidein Frontend
- WMS Factory
- Components
- FAQ

## Components

- Overview
- User Pool
- User Schedd
- GSI
- JWT
- HTCondor

### JWT Authentication

Jump to:

1. Quick Reference
2. Required Software Packages
3. Installation
4. Configuration

- JWT Quick Color-coded Guide

## 1. Quick Reference Guide to JWT Authentication Setup

JWT configuration is conceptually similar to GSI configuration.
With GSI configuration:

- the auth files are either cert/host pairs or proxies
- HTCondor identities are mapped via condor_mapfiles.
- the locations are either specified in XML configurations or live in a well known default

With JWT configuration:

- the auth files are either IDTOKENS or SCITOKENS
- HTCondor identities are mapped via condor_mapfile for SCITOKENS.
  - This is usually only done on an HTCondor CE in GWMS
- HTCondor identities are taken from the subject: claim for IDTOKENS
  - IDTOKENS can have identities mapped with a condor_mapfile but this is typically not done in GWMS
- the locations are either either specified in XML configurations or live in a well known default

Service | Comments
User Pool (Collector) | The user pool needs to have IDTOKENS authenticating it from all of the separate HTCondor machines it authenticates with. This means that if the User Collector, Glidein Pool Collector, User Schedd Nodes, and Glidein Frontend are all on separate nodes, they must each provide IDTOKENS to each other. Admins for the various nodes must coordinate condor_token_request and condor_token_request_approve operations to distribute IDTOKENS as needed. The received tokens are placed in /etc/condor/tokens.d with root ownership IDTOKENS can be mapped to users via condor_mapfiles but are usually not in a GWMS installation
WMS Pool (Collector) | Same IDTOKENS requirements as User Pool Collector for HTCondor Daemons on distinct machines. Be aware that if there are multiple collectors for load balancing or HA, such as mycollector.fnal.gov and mycollector.cern.ch, the processes should be supplied with two IDTOKENS issued from both mycollector.fnal.gov and mycollector.cern.ch
Glidein (Through Glidein Factory) | An IDTOKEN is generated by the frontend and passed on to the glidein via the factory. The factory creates a glidein with this IDTOKEN as a payload, which it uses to authenticate back to the frontend collector. Operators do not typically need to involve themselves in this process unless an IDTOKEN is suspected of being compromised and needs to be revoked.
Glidein Frontend | If the frontend is running HTCondor daemons, they have the same IDTOKEN requirements as Collectors above The frontend admin needs IDTOKENS for the frontend uid in ~frontend/.condor/tokens.d and they must be owned by the frontend user. See the JWT Quick Color-coded Guide for a description of the subject these tokens need. A SCITOKEN must be generated and placed in the <credentials> section of /etc/gwms-frontend/frontend.xml to authorize submission to CEs The CE admin must edit /etc/condor-ce/mapfiles.d/10-scitokens.conf to map the SCITOKEN to a uid. The Factory admin needs to ensure that an <entry> with auth_method="scitoken" exists in /etc/gwms-factory/glideinWMS.xml
Glidein Factory | Same IDTOKENS requirements as User Pool Collector for HTCondor Daemons on distinct machines. As CE's switch from GSI to JWT authentication they need corresponding <entry> lines with auth_method="scitoken" in /etc/gwms-factory/glideinWMS.xml
User Schedd | Same IDTOKENS requirements as User Pool Collector for HTCondor Daemons on distinct machines.

## 2. Required Software Packages

- The Open Science Grid Yum Repositories"
- The Epel Yum Repositories
- Machines Capable of installing and running Epel and OSG RPMS. Currently Red Hat 7 and variants.

## 3. Installation

Installation of GlideinWMS Factory or Frontend v 3.7.4 or greater will be JWT authentication compatible.

- Frontend Installation Guide
- Factory Installation Guide

## 4. Configuration