Participants:  Andrii, Brian, Dave, Enrico, Federica, Hannah, Jeff, Jeny, John, Julie, Linda, Maarten, Masood, Mine, Petr, Roberta

Notes:   (please send corrections)

We went back to the slides on Rucio token exchange workflow scenarios that we last discussed on Aug 26.
Brian and Dave added comments reflecting the discussion during this meeting.
It was pointed out that where the slides mention IAM, one should read "IAM or CILogon", i.e. the authZ service for a given VO.

Slide 2:

• Question on access token lifetime for Rucio client upload / download.
  • The client needs to be able to verify the checksum of an uploaded file.
  • The token lifetime could be made somewhat longer for that.
  • Or a renewal workflow would have to be implemented.
• The client can only do what is approved by the Rucio server (or DIRAC etc.).
  • The SE can still benefit from knowing who initiated the operation in question.
  • Helps with traceability, but also allows blocking just 1 user instead of the whole VO.
  • That functionality may come as a future enhancement, not critical at this time.
• CILogon currently supports token exchange only for the same client.
  • Impersonation is expected in the coming months.
• What does an access token look like on the WN?
  • Have to watch out for sending one that is too powerful, like today's X509 proxies.
  • The workflow management system can restrict the token to what it should be used for.
  • Could be down to an individual file, like in ALICE.
  • That would be expensive and may well be overkill for many cases.
  • Depends on what is convenient for the VO and good enough in practice.
  • CMS jobs need to stage out files that will be registered later.
  • ATLAS jobs need to have the Rucio client be able to do both steps.
  • ALICE Run-3 workflow checked after the meeting:
    • A pilot job gets submitted with a job token.
    • The job token can be used to request a task from the central task queue.
    • The task comes with its own token that includes the user identity.
    • The latter token can be used to request an access token ("envelope") for a file.
    • The central file catalog hands out tokens only for paths to which the user has access.
• FNAL has ~20 small communities that need to be mapped to different groups in dCache.
  • UK IRIS project is working on support for multiple VOs in a single Rucio instance.
  • Big VOs each have their own instance (or equivalent).
• Which entity should know about paths, ACLs etc?  Rucio?  IAM/CILogon?  Both?
  • Rucio is the VO data management system and should have the complete picture.
  • In principle some of it could be "outsourced" to IAM/CILogon.
  • Suggestion: use IAM/CILogon only for what would be awkward to do in Rucio.
  • Today the knowledge of paths and ACLs is spread between Rucio and SEs.
    • The latter should need much less detailed configuration when tokens are used.
    • A given SE directory may be used for storing unrelated files, hashed by name.

Slide 3:

• By having all token exchanges go via IAM/CILogon, SEs need to implement less.

Slide 4:

• Only an FTS registered with IAM/CILogon can exchange tokens obtained from Rucio.
• This would need to be documented.

Actions:

• Invite FTS and Rucio devs again to discuss token exchange workflow details.