Choose timezone
Your profile timezone:
WLCG AuthZ Call
→
Europe/Zurich
Description
Proposed agenda:
- Discussion: JWT usage and exchange in FTS workflows
- Workflow is described in our vCHEP paper (attached)
- Questions around...
- lifetime of refresh tokens
- whether Vault should be used instead of refresh tokens managed by the client
- Proposal: security review of OIDC based grid (similar to what happened for EGI in 2016)
- Talk proposal: oidc-agent and myToken, from Uros and Gabriel - August or September?
Zoom meeting:
Please ensure you are signed up to project-lcg-authz@cern.ch to receive the meeting password!
Join Zoom Meeting
https://cern.zoom.us/j/94718857994
Meeting ID: 947 1885 7994
Password: <see email>
One tap mobile
+41432107042,,94718857994# Switzerland
+41432107108,,94718857994# Switzerland
Dial by your location
+41 43 210 70 42 Switzerland
+41 43 210 71 08 Switzerland
+41 31 528 09 88 Switzerland
+33 1 7037 9729 France
+33 7 5678 4048 France
+33 1 7037 2246 France
Meeting ID: 947 1885 7994
Find your local number: https://cern.zoom.us/u/abjrVtLBu4
Join by SIP
94718857994@188.184.85.92
94718857994@188.184.89.188
Join by H.323
188.184.85.92
188.184.89.188
Meeting ID: 947 1885 7994
Password: <see email>
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.
The agenda of this meeting is empty
