Rucio & FTS Token Workflow call

Tuesday 7 Dec 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>

Participants: Marcelo, Petr, Hannah, Martin, David Cameron, Masood, Jim, John, Federica, Maiken, Dave, Andrea, Maarten, Federica, John, Adeel, Alison, Paul, Tayk, Douglas

Apologies: UKRI

Notes:

• See Google slides 
• Idea for Rucio clients to get a very basic token initially from IAM (no capabilities, just identity), which is sent to Rucio server to request a more powerful token
  • Alternative to allow Rucio clients to get read capabilities but not write without going to Rucio Server
• Rucio Client must not have too many privileges since it's a public client, all authorization must be based on the user (token signature must be verified by Rucio server to check that it is a valid user)
• Rucio Client does contain some powerful resources, i.e. the tokens, but they are only valid for a particular timeframe
• Powerful tokens contain Rucio identity (act) as well as User (sub). Was a little unclear which one should be in which claim.
  • Not a requirement that red token (powerful token) is under Rucio identity, but the token should contain both
  • How could we chain delegation? act claim can show multiple actors e.g. Rucio and FTS 
• How many tokens should be used?
  • More tokens with fewer capabilities (i.e. less powerful?) 
  • Rucio can request the correct audience for each token
  • If token has expired goes back to either Rucio Server or IAM 
• Could the Rucio Server refresh red tokens rather than exchanging the original black token again? yes, either would work. Would need to see what is more performant 
• Don't want to surprise the user or the storage elements with powerful token permissions. User should consent only once, not for each login. Need to see when the consent can be given. Policy issue to be solved. Limited proxies were used for job submission in the past, but not for data access
• Currently no way to say that token cannot be further exchanged (wish list)
• FTS will run into the issue of tokens expiring and it will need to renew them as well
  • Have cluster storage broken out by local uid/gid, need to map ACL correctly (based on individual users) 
  • Need both subject and scope and there will be tools to go from subject to human (followed in traceability discussion)

Actions: 

• Andrea/Francesco: provide more insight on how requests are done (i.e. http requests) and claim content