Participants:
Maarten, Dave, Martin, Uros, Irwin, Andrea, Jim, Petr, Rose, Jeny, Gabriel, Linda, Andrei, Andrii, DaveK, James, Julie, Marcelo, Federica, Tom, DavidC, Mischa
Notes:
- Refresh tokens:
- Refresh tokens can be renewable or not
- Our JWT spec doesn’t consider this, sets maximum lifetime to 30 days
- Need to find a balance for user login frequency, balancing usability and security (plus helps them to remember how to do it!)
- HTCondor flow
- Indefinite Refresh token lives in Vault, effectively becomes a token issuer (privileged server)
- Vault token is like a short-lived Refresh token, can be presented to vault with no additional credentials
- Big advantages here
- Flexibility of authentication, can also use kerberos after initial set up
- Users don’t have to manage clients or additional passwords
- FTS flow
- One concern is exchanging short access token for long refresh token
- Rucio could get a more precise token rather than FTS since also knows the scopes required (i.e. storage elements)
- FTS can make slightly more precise choices about scopes or splitting up tokens
- Exchange in IAM mostly supports impersonation, i.e. you cannot tell whether it’s part of a delegation chain. In delegation you would have visibility of links in the chain.
- Exchange is adding specific scopes, actually increasing how many capabilities are included in the token.
- IAM does more than OAuth standard, checks what a token was minted for. Have permissions for exchange based on where a token is coming from and where it is going to
- Comparison
- FTS controls 3rd party copy, SEs can be contacted in other ways like gfal independently
- How are users authenticated to Rucio/FTS flow?
- Could be done in multiple ways
- Possible to use Vault to get initial token minted for Rucio, then Rucio would need to exchange it for the target service (e.g. FTS)
- Will initial token be needed to get access to results and storage? Does it need to be a powerful initial token?
- User may know what’s required in terms of storage
- Rucio could use Vault to get more powerful tokens
- myToken could do similarly
- We need to understand how Rucio client comes into this for Rucio upload and download. Initial access tokens may need to be more powerful.
- Does Vault need to be exposed to the internet?
- Is it reasonable for people to go to lxplus first?
- Rucio download is currently run on e.g. laptops so if it needs to integrate with Vault Vault must be exposed to the internet
- How can the user be authenticated to the Rucio Client and similar? Vault required or could it be a public client?
- We are limited by Vault’s Go libraries, currently not able to do certain flows (downscoping and audience restrictions) that are supported by IAM
- Can achieve downscoping through token exchange rather than refresh
- Using Vault instead of multiple different clients limits blocking capabilities (if other services are no longer clients). Question of whether we want to centralise power in a single client or have it split out.
- Suggestion to do a component security review of tokens in WLCG, lots of support
Future discussions:
- Does Vault need to be exposed to the internet?
- Add renewable refresh tokens concept to documentation
- Do we want to centralise power in a single client (Vault) or have it distributed?
Actions:
- @Andrea, demo of scope configuration in IAM per client
- @Martin, consider the flow with Rucio Client as well, how are initial permissions added to access token sent to Rucio server. Diagram for next call
- @Andrea to organise next call, August 5th
- @Hannah start the ball rolling for the security review of WLCG with OAuth
There are minutes attached to this event.
Show them.