Choose timezone
Your profile timezone:
WLCG AuthZ Call
→
Europe/Zurich
Description
Proposed agenda:
- Announcements/Info
- VOMS Migration Strategy input
- IAM support migration to CERN IT-CDA
- Discussions:
- Central Suspension - DavidC
- Capability Sets
- Dave to add examples & motivation
- https://github.com/WLCG-AuthZ-WG/common-jwt-profile/pull/10
- Standardisation of CE capability requirements
- id token claim for use by vault with kerberos (Dave, Andrea, Hannah)
- Token Propagation Workflow Doc (this activity never took off)
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: DavidC, Maarten, DaveK, Andrei, Tom, DaveD, Romain, Enrico, Federica, Irwin, Jeny, Jim, Julie, Marcelo, Jeffrey, Sven, Fabrizio
Notes
- Central suspension
- This meeting is to set the scene for future meetings
- EGI can centrally suspend a DN, some question over whether this happens in practice. Argus is not necessarily used.
- Designed so that there were various policy points where policies could be evaluated and enforced. Wanted to allow others to apply policy as well as just certificate revocation. Was an EU focused architecture.
- We should avoid making something that is too complex. Current system is over-engineered.
- We do need to have the same, or similar, functionality.
- Who should be involved in defining this?
- Technical
- Policy
- How does this happen technically?
- How does this overlap with threat intelligence sharing?
- VO level suspension is effectively solved (this is what we have). However, we have no possibility at the site level when using native OIDC.
- How can we deal with people overloading a site? Sites would want to be able to block activity from that user immediately.
- We have never had an incident where site level blocking was seen as critical, however we shouldn't assume this for the future
- Capability sets
- If a client requests a capability set and a scope that happen to be the same e.g. storage-read but for different paths, they should both be returned
- Returning an error if not entitled
- Plenty of error handling in the OIDC spec
- Consider adding how the error response should look
- https://tools.ietf.org/html/rfc6749#section-4.1.2 error response could be access_denied
- We should make it consistent between group requests and capability set requests
- IAM needs to start issuing kerberos principal name
Actions
- Hannah to send WLCG IAM DNs to Maarten to be included in RPMs
- DavidC form subgroup to work on this topic
- Hannah to look up how we deal with requesting groups that we're not entitled to
- Dave to edit capabilitiset
- Remove part about "different values"
- Make groups and capabilityset request failure consistent
- Andrea and Hannah to start issuing kerberos principal claim, see with DaveD which claim name to use
There are minutes attached to this event.
Show them.
