Notes grid map file
- Do we need to be tracking gridmap file usage atm?
- We need to test during this transition period where we have IAM and VOMS available in parallel.
- Two main use cases, CASTOR and EOS
- Can no longer just have open access to this information due to GDPR
- Already in VOMS need special privileges
- Should anyone be able to see who is in CMS VO just because they have a certificate? You can browse the list of DNs but cannot get any more information atm
- In IAM must have a registered, authorised client
- IAM API has been used by ESCAPE and EOS will use soon
- Will want to do similar with token subjects
- Mapping to local accounts is done per service, VOMS releases DNs and groups/roles. Logic has to be done by service
- Does IAM have a `role` available that a site could use to select a subset of users?
- Roles (i.e. optional groups) and principal group exist in IAM (backwards compatible)
- At last hackathon agreement that would be good to have an interface defined that would be like lcmaps
- What are we missing?
- IAM does already support generating the same data for DNs
- Will need better interfaces for client registration and management
- We are missing an agreement on how the mapping will look for token based use cases
- Petr wants support for user directories in token based model, not clear what storage should provide. Does the API provide what is needed? Need to provide some guidance on home directory use
- Support for capabilities more complex
- IAM can be extended as we need but we need to be careful not to put service level logic into IAM
- Next steps
- Doc with
- Current spec (Maarten?)
- IAM backwards compatible spec (Andrea)
- IAM token spec
- Any edge cases we need to consider
Actions
- Maarten to go through comments on timeline
- Hannah start a doc and send it around to list