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