Attendees: Hannah, Brian, IanC, Mischa, Andrea, DavidC, Tom, Nicolas, Julie, Linda, Mine, Irwin, DaveK, Burt, Will
Notes:
- CMS IAM
- CMS IAM instance being set up at CERN
- IAM on Openshift, with NGINX in front
- DB from CERN's DB on demand
- HR DB API also running on Openshift
- Aim to complete by end of April
- https://cms-auth.web.cern.ch
- Openshift Project already set up
- Jira project https://its.cern.ch/jira/projects/WLCGTOKENS
- TO DO
- Much later can decide on external DNS load balancers to rename endpoints
- CERN SSO integration
- Monitoring and logs to Elastic Search in progress
- Need Grid host cert on VOMS endpoint but currently blocked by CA policy (and technical limitations) on Openshift
- Currently IAM only integrates with VOMS 3 and not VOMS 2 due to bug
- We are going to need to do training with VOMS maintainers (possibly in May)
- Andrea has some documentation already
- Need to understand what they are expected to do? Register? Migration? Large scale onboarding?
- AUP: WLCG already using the WISE AUP, we can just point people to this
- Currently CMS users link their DN to their CERN account, can we get the DN directly into CMS IAM?
- Unfortunately seems that people really still need a CERN account and cannot fully use Federated Identity
- Client Tools Technical Investigation
- Ask all to read through and comment
- Policy requirements should lead discussion
- Ask DavidG if there are any (generic) guidelines for public vs private clients etc
- https://www.eugridpma.org/guidelines/trustedstores/
- https://www.eugridpma.org/guidelines/aaops/
- This tool should be relevant for both WLCG and CERN, involve more CERN members
- Groups in WLCG Schema
- Paul M raised Qs about group membership in profile, expression and request
- Should clients enforce hierarchical structuring of groups?
- Andrea's opinion, should keep simple to allow use of generic libraries etc
- Prefers that groups are matched on string matching only
- Brian prefers the logic in the clients (but it does get complicated outside a flat hierarchy scenario)
- Could implement group hierarchy knowledge in IAM
- Either way there is not much hierarchy going on in WLCG so this is low risk
- Summary: suggest that token issuers do hierarchical group membership, relying parties must only use groups asserted in tokens (no calculations) and only use standard scope style string matching (plus remove VOMS-like text from schema)
Actions:
- Next time just publish one video conference details :)
- Ask all to comment on Client Tools
- Ask DavidG for any guidelines on public vs private clients etc
There are minutes attached to this event.
Show them.
