Components
JWT Authentication
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 seperate HTCondor machines it authenticates with.
- This means that if the User Collector, Glidein Pool Collector, User Schedd Nodes, and Glidein Frontend are all on seperate 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 recieved 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 collecters 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.
- 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.
|
Installation of GlideinWMS Factory or Frontend v 3.7.4 or greater will be JWT authentication compatible.