Attendees: Hannah, DaveK, Linda, Mischa, Maarten, Alex, Jeny, Andrea, Jim, DaveD, Brian, Paul, DavidC, Joel, Enrico
Notes:
- DaveK to start an activity to do a risk assessment with aim to define assurance policies for WLCG. Start with a group mainly from the GN4 Project (to make faster progress) and then bring back to the WG.
- Vault workshop last Friday did enable people to set up vault servers, identified some more thorough instructions for WLCG integration.
- Andrea demo'd scope selection policies
- Some deny rules
- Some additional permit rules, i.e. individual users are able to request certain scopes
- Additional rules enable scopes per client (currently in the UI)
- Point from Maarten, can we have default deny rather than potentially confusing config?
- We don't want to deny everything by default. Most scopes should work for everyone but some critical ones MUST be authorised by client and user. Most for WLCG will be authorised.
- Scopes are treated as simple strings. IAM was modified to allow requesting more restrictive scopes i.e. /cms/adsdjk/sdas when the user is entitles to /cms (added path semantics to IAM)
- Requests from Dave/Jim
- #1 I request /path but am only entitled to /path/a, I want to get /path/a
- #2 I send a group scope and get all relevant capability claims returned
- How do we authorise specific directories? Perhaps this is not a case for capabilities, since it requires a lot of knowledge in IAM, i.e. authorisation rules per home directory (or a syntax with $USER based on a sub)
- Several opinions that this is not how IAM should work, it should not need to be that aware of the internal logic of auth for a client. Group based authorisation is more useful for these cases.
- Worth producing some example scenarios (use cases) for how to model authorisation
- Produce some authorisation examples explaining where we imagine capabilities vs groups. This might allow us to understand whether we do need to make modifications to support Jim/Dave's use cases.
- Jim had understood that you have to pick between groups and capabilities - you can have a mixed model. Although we did guide that perhaps better to pick one. Paul had also understood that mixing was not advisable. Assumption that you are NOT allowed to do anything for which you don't have the capability, which does not mesh well with groups.
- DaveD was expecting that CiLogon would feed auth into IAM somehow, this is probably a different assumption
Actions
- Andrea and Hannah to draft some guidance on using capabilities vs groups in the schema doc
- Hannah - Start a mail thread to help define use cases with different authorisation needs
- Hannah - Next call schedule more in depth discussion on authorisation models
- Hannah - Send doodle to plan next call
There are minutes attached to this event.
Show them.
