this is maybe a bit complex for the list, the rough setup
is you need a
get_token_cmd should perform some checks and then write the
token to <stdout>
The receiving host is the CREDD_HOSTÂ which is most likely
the SCHEDD_HOST running the credd
If you want todo additional credd manipulation on the sched
or on the worker you need to come up with a daemon that will
be called byÂ
If you want we can maybe discuss this in more depth in a
zoom session ?
Dear all,
our question is related to the refreshment of access token
fetched in the job sandbox.
We want to develop a Credential Monitoring component for our
particular need, and be able to use the File Transfer Service
implemented in HTCondor.
We have developed some preliminary version of this Credential
Monitoring plugin, following as guideline the plugins already
implemented in [1].
Our strategy for the token management is the following:
1. The user has an oidc-agent configured for a specific OIDC
provider [2] and the Mytoken service [3].
2. Before submitting jobs via HTCondor, the user generates a
Mytoken via the command line.
 Â
ÂÂÂ This Mytoken is the equivalent of a refresh token: this is
the object we manipulate to generate the first access token,
ÂÂÂ and to generate further access tokens when refreshment is
needed.
ÂÂÂ The refreshment procedure is implemented in the Credential
Monitoring plugin, via a POST request using the HTTP python
library "Requests".
3. Besides the generation of a Mytoken via the command line
before jobs submission, this procedure should ensure that the
token management is transparent to the user.
Apart from the Credential Monitoring plugin, we also wrote the
equivalent of the executable [4] and modified the CMakeLists
[5] accordingly.
We also took care to define the following macros we make use
of:
DAEMON_LIST
CREDD_HOST
CREDMON_OAUTH
CREDMON_OAUTH_LOG
CREDMON_OAUTH_TOKEN_LIFETIME
SEC_CREDENTIAL_DIRECTORY_OAUTH
SEC_DEFAULT_ENCRYPTION
So far, we were not able to successfully test the
implementation of our Credential Monitoring Plugin.
Our question is the following: does the approach described
above comply with the strategy implemented in HTCondor?
I went through the credd and file transfer cpp files, but was
not able to get a final answer.
As an example, in our approach, we don't need to define the
variables "<OAuth2ServiceName>_*" in the HTCondor
configuration, neither the "use_oauth_services" in the job jdl
file.
All we need is already implemented in the POST request in the
Credential Monitoring plugin. We do not even need at all the
configuration variables <OAuth2ServiceName>_CLIENT_ID
and <OAuth2ServiceName>_CLIENT_SECRET_FILE.
Thanks a lot in advance for your answer and advice!
Kind regards,
Benoit
[1]
https://github.com/htcondor/htcondor/tree/main/src/condor_credd/condor_credmon_oauth/credmon/CredentialMonitors
[2]
https://login.helmholtz.de/home/
[3]
https://mytoken.data.kit.edu/#mt
[4]
https://github.com/htcondor/htcondor/blob/main/src/condor_credd/condor_credmon_oauth/condor_credmon_oauth
[5]
https://github.com/htcondor/htcondor/blob/main/src/condor_credd/condor_credmon_oauth/CMakeLists.txt
_______________________________________________
HTCondor-users mailing list
To unsubscribe, send a message to
htcondor-users-request@xxxxxxxxxxx with a
subject: Unsubscribe
You can also unsubscribe by visiting
https://lists.cs.wisc.edu/mailman/listinfo/htcondor-users
The archives can be found at:
https://lists.cs.wisc.edu/archive/htcondor-users/
![[Computer Systems Lab]](http://www.cs.wisc.edu/pics/csl_logo.gif){kind=logo}