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