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
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/