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