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}