Choose timezone
Your profile timezone:
WLCG AuthZ Call
→
Europe/Zurich
Description
Proposed agenda:
- Discussion: JWT usage and exchange in FTS workflows
- Workflow is described in our vCHEP paper (attached)
- Questions around...
- lifetime of refresh tokens
- whether Vault should be used instead of refresh tokens managed by the client
- Idea is to start from where we left off at the last call
- RUCIO client token workflows
- Presentation by Martin
- OAuth scope authorization management in IAM
- Andrea's presentation and demo on how access to scopes is authorized in IAM
- Andrea's presentation and demo on how access to scopes is authorized in IAM
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:
Andrea, Petr, Dave K., Enrico, Irwin, Martin, Julie Marsh, Linda, Jim, Roberta Miccoli, Gabriel Zachmann, Jeny, Dave D., Mine, David Crooks, Andrii Lytovchenko, Maarten, Brian
Notes:
- Discussion: JWT usage and exchange in FTS workflows
- We started from where we left off at the last call (presentation is linked in the agenda)
- Discussion on Vault becoming a bottleneck/SPOF
- Vault can be deployed in HA, and it seems very scalable from Dave's tests (250hz for a 2-core machine, but the token issuer was not touched in the testing)
- Q(Maarten): how would we manage a multi-site deployment for Vault? Would it be possible? It wasn't possible for MyProxy. To be further discussed/ understood
- Application and user-level traceability aspects would also need be discussed in a dedicated call. In the current model htgettoken/vault would use a single oauth client for different apps, need to be understood if a different approach is possible/needed depending on the use case
- Brian raised a concern about depending on an open source product that's heavily based on a single company (Hashicorp)
- RUCIO client token workflows
- Presentation by Martin (linked to the agenda)
- Currently a very privileged token, obtained out-of-band (with oidc-agent or similar tools) is used to interact with the RUCIO server and with the storages, following closely the VOMS model
- Discussion on how the token should be limited to talk to storage elements. Comment (Brian,Andrea): Token flows management is more safely implemented on the RUCIO backend than on the client
- Probably the more scalable approach for token attenuation that would limit impact on the central token issuer, is to let RUCIO (actually a library that RUCIO could use (e.g., GFAL)) exchange the VO token with a storage-issued token (aka Macaroon) that would be used for the file transfers
- Agreement that this token exchange should be discussed in a future call of this group, as it impacts development agendas on SEs, GFAL, FTS, RUCIO (Mihai and other relevant people should be invited to join)
- OAuth scope authorization management in IAM presentation
- Presentation post-poned for a future call (no time left)
Next call:
Thursday, August 26th, 15.00 CEST
There are minutes attached to this event.
Show them.
The agenda of this meeting is empty
