Rucio & FTS Token Workflow call



Continue token flows for Rucio


Zoom meeting:

Please ensure you are signed up to to receive the meeting password!

Join Zoom Meeting

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:

Join by SIP

Join by H.323
Meeting ID: 947 1885 7994
Password: <see email>

Rucio & FTS

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


  • 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


  • 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”


There are minutes attached to this event. Show them.
The agenda of this meeting is empty