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.