Project

General

Profile

Feature #25450

Change IDTOKEN use to be more aggressive by delaying the checks

Added by Marco Mambelli 3 months ago. Updated 11 days ago.

Status:
Resolved
Priority:
High
Assignee:
Category:
-
Target version:
Start date:
01/28/2021
Due date:
% Done:

0%

Estimated time:
Stakeholders:
Duration:

Description

IDTOKEN authentication should be used by the Glideins if:
1. User pool collector is compatible
2. Frontend and HTCondor on Frontend are compatible
3. Factory and HTCondor on it are compatible
4. HTCondor tarball is compatible

The current proactive check may not use IDTOKENS when could be possible, e.g. the listed version of condor is misspelled or is default (because it is checking for the version number comparing the value of the variable CONDOR_VERSION.

Unless some drawback is seen in the new approach proposed below, this should change.
The token is small, so it is cheap to send it anyway, therefore the checks should be delayed as much as possible (no ahead) and fall-back to x509 should be used if something fails.

a. If the Frontend can generate the IDTOKEN is should assume that 1 and 2 are met and send the IDTOKEN to the Factory
b. If the Factory receives IDTOKEN and can forward it encrypted to the Glidein it should do so
c. condor_startup.sh (generating the condor configuration) should check the version of the condor binary and if it is compatible w/ IDTOKENs it should set in the configuration IDTOKEN as the primary authentication method. x509 can be capt as fall back (2nd in the list)


Related issues

Blocked by GlideinWMS - Feature #25247: Improve the generation of Glideins' idtokensResolved11/24/2020

History

#1 Updated by Marco Mambelli 2 months ago

  • Blocked by Feature #25247: Improve the generation of Glideins' idtokens added

#2 Updated by Dennis Box 11 days ago

  • Status changed from New to Resolved

Also available in: Atom PDF