indigo-iam/iam

Please allow exchanged and refreshed tokens to have the same durations/lifetimes as their originating access-tokens

Opened this issue · 9 comments

murrayc3 commented

Assuming the duration/lifetime of an access-token is:

  • exp - nbf

In order to reduce confusion, one should be able to configure IAM to give exchanged and refreshed access-tokens the same duration/lifetime as their originating access-token.

The following "full WLCG lifecycle" test shows that it is very confusing when the token exchanger/refresher client (FTS) has a different token duration/lifetime (1 hour in this example) than the end-user client (6 hours in this example). Please note that FTS must exchange end-user tokens for a refresh-tokens as soon as it can. The example shows that in this particular case the end-user does not get the token lifetime they expect.

[c7] fts_tokens (master) > ./full_token_lifecyle.py config.ini 
issuer                             = https://dteam-auth.cern.ch

user_client_id                     = 45541bfd-09d2-4fec-9328-ca5528f140f8

fts_client_id                      = af32d0c4-f51f-4b08-9aec-a423a3e0c3cb

src_token jti                      = 8b7b953a-f60c-4035-a5e8-3b5814f50489
src_token duration                 = 21600
src_token_from_exchange jti        = f892aee3-f8b0-4d7b-b5ce-7e6535cc3cdd
src_token_from_exchange duration   = 3600
src_refresh_token jti              = a7c61162-7741-48d1-90d4-03853199266b
src_token_from_refresh jti         = daca2ebe-da75-4788-9aa6-d9df07697126
src_token_from_refresh duration    = 3600

dst_token jti                      = 02d17c12-fa20-4d83-a723-4dd93a010abe
dst_token duration                 = 21600
dst_token_from_exchange jti        = 358f95b6-8b1d-4163-ab0c-2fb776f66cfe
dst_token_from_exchange duration   = 3600
dst_refresh_token jti              = da730b25-e5ee-4418-bbd2-536035d8e187
dst_refresh_token_from_refresh jti = da730b25-e5ee-4418-bbd2-536035d8e187
dst_token_from_refresh jti         = 13dfd341-9bac-4b12-a617-59179883f9e0
dst_token_from_refresh duration    = 3600
[c7] fts_tokens (master) >
rmiccoli commented

Hi,

the AT/RT duration is already configurable by changing the following environment variables:

  • DEFAULT_ACCESS_TOKEN_VALIDITY_SECONDS (default is 3600)
  • DEFAULT_REFRESH_TOKEN_VALIDITY_SECONDS (default is 2592000)

These are applied to ALL clients.

However, the AT/RT duration can also be changed PER client, so if you want the same values for FTS client and end-user client you should change them through the IAM dashboard ("Tokens" section of the client configuration).

murrayc3 commented
giacomini commented

Hi, Unfortunately what you suggest does not solve the problem for the end-users of FTS. Clients of the FTS service will not know, or probably care about the timeout settings of the FTS service itself. Different experiments and end-users will expect the time of validity of their access-tokens to be preserved (give or take a few seconds) during the FTS exchange protocol.

Just to understand the use case: aren't the ATs obtained by FTS via token exchange an internal business of FTS? why should end-users see and/or care about them?

murrayc3 commented
murrayc3 commented
maarten-litmaath commented

Hi Steve,
you wrote:

"[...] we never register FTS within any of the IAMs [...]"

But how would an FTS then be allowed to do token exchange operations?

In fact, there are FTS clients registered for ATLAS, CMS and LHCb that
have the token exchange grant configured. The one for LHCb says:

Client used by FTS3 service at CERN for token exchange and refresh

In any case, as things have been implemented thus far, "user" tokens are
just to get transfer jobs accepted by the FTS, which then can and should
have its own timings for trying to make those transfers actually happen.

As we will look further into the token workflows between Rucio/DIRAC and
the FTS to improve the scalability and stability of all components involved
in the data transfer machinery, we might end up with the client having to
provide the source and destination tokens the FTS will actually use,
without any exchanges (and potentially even without any refreshing)...

  • 👍1
giacomini commented

@murrayc3, of course I believe you and of course we are available to clear all misunderstandings that can arise. I hope we can sort most of them via the documentation. We are also available to adjust the behavior of IAM based on feedback from the field. Specifically on the token exchange, the RFC at some point says: "[...] the expiration time of the output token may be influenced by that of the input token [...]"; but before making changes, let's agree on a sensible behavior.

About the current flow of tokens, I wonder why FTS cannot simply be considered a trusted client and ask all the tokens that it needs. We could extend the policy engine in IAM to accommodate such an approach. But this discussion is OT for this issue.

murrayc3 commented
murrayc3 commented