Rucio & FTS Token Workflow call

Tuesday 23 Nov 2021, 15:00 → 16:00 Europe/Zurich

Agenda:

Continue token flows for Rucio

• Google Doc
• Slides with Rucio Flows

 

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>

"Act" token claim (actor)

Rucio & FTS

Participants: Andrea, Mario, BrianB, Rose, Linda, BrianD, Federica, Jim, John, Maarten, Marcelo, Martin, Mihai, Timothy, Petr, Roberta, Rizart, Alison, Tom, Francesco, Xiaomei

Notes:

• 3 scenarios proposed in attached slides, number 2 was the best option
• Questions
  • Do storage elements just see the “Rucio server” tokens, or do they see individuals?
    • Currently supports both a shared user (for transfers) and user proxies (for uploads and downloads), traceability required
    • Depends whether group based or capability based wanted? Initial reaction = capability
  • How does Rucio know which scopes should be requested in a token?
    • Should know which operations are required on which files
    • If user tokens required may need to set up group based capability authorisation in IAM (could get large and a lot of logic in IAM)
      • Hopefully just simple rules in IAM, e.g. anyone in the VO can read a particular path
  • Handling of refresh tokens?
    • Not really done (would go back to the server and get a new token)
  • Traceability
    • We need a way for Rucio server to be able to request a token for a particular user using its own credentials
      • Possibly “act” actor claim if getting tokens where subject is “Rucio server” i.e. shared credential
      • Should ensure the “sub” is maintained somehow for traceability purposes
  • Which flow used at “point 3”? Client credentials or token exchange?
    • Client credentials, with “act” actor embedded to preserve original subject
      • Storage elements would have to handle slightly more complex tokens
      • Some standards, e.g. UserInfo would not work
    • Token exchange
      • May require more logic within IAM r.e scopes
  • What does the Rucio Client do when it gets an error or an expired token?
    • Requests a new token from the Rucio Server (who goes back to IAM)
• We typically want a token for each storage element in case it fails and could be retried
• Rucio Client = public client?
  • Could be reasonable, if token just gets back basic permission about user

Actions:

• Hannah: schedule next call for 7th at 15:00
• Andrea: clarify token exchange and “act” claim
• Andrea/Francesco: Make more detailed slide on “point 3”