WLCG AuthZ Call

Thursday 9 Jul 2020, 15:00 → 16:00 Europe/Zurich

Proposed agenda (to be rolled over): 

• Bearer Token Location Proposal - close the document
• Client Tools Technical Investigation
• CMS Auth instance status https://cms-auth.web.cern.ch
• Aud guidance from profile doc
• Next steps CMS IAM
• Mapping user accounts in a token infrastructure
• Big picture discussions
  • Should we be relying on the CERN IdP? Pros vs Cons

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>

Attendees: Hannah, Andrea, Maarten, Brian, Irwin, Jeny, Julie, Tom, Mine

Notes:

• Bearer token doc done
• Client Tools
  • Demo not quite ready, the oidc-agent part is pending
  • Prototype developed by Andrea, using Device Code Flow with browser (no need to authenticate twice since session established in browser)
    • Do need to go to browser twice, particularly for consent part
  • How can we remove the need to do the action (authenticate/consent/other) twice?
  • Doesn’t seem right to silently allow people through, we also don’t want people to be exposed to additional risk
  • Suggestion to add logic to consent, e.g. if they are the owner of the client then no consent needed (not supported by Keycloak)
  • We need some kind of balance between different legalities (e.g. under GDPR consent is invalid in a work context)
  • The VO terms of use and privacy policy already cover consent at a higher level
  • This workflow is really Inform rather than Consent
  • Summary: we need some kind of information screen as people go to a new client for the first time (not called consent) but this shouldn’t be shown if you are the client owner (this is not supported in Keycloak)
  • Can we think of a way that oidc-agent is used by multiple people? i.e. client credentials are shared
  • Vault already planned to be used, sounds likely that can combine oidc-agent and Vault (add to list)
  • Centrally run oidc-agent with Vault - there may be a gap for places (e.g. labs) that cannot deploy Vault (though backup flow is the individual oidc-agent registration). Unclear whether Vault would need to be deployed locally by each lab (linked directly to an LDAP)
• Q from Mine: HTCondor cannot process WLCG Groups, are we going to use groups to submit jobs or just capabilities?
  • Since pilot jobs, capabilities seems relevant. Wait until there is a use case before developing.
• Problem with CMS IAM instance, letsencrypt certificate was not refreshed and expired
  • Need to get a Sectigo certificate for VOMS compatibility?
• CMS people have had a look at IAM, a bit of feedback
  • People working on new services are quite happy
  • Several things have only gone as far as prototypes due to lack of users (assumed green light)
  • VOMS admin requests to cut out as many manual things as possible for the user (i.e. not have a VO admin click OK)
    • Some feedback from GDB said that we need to have a manual step
  • Why should they use this rather than the CERN OIDC endpoint?
    • Could move everything to the CERN IdP
    • There should be some documentation somewhere (in IT?)

Actions:

• Hannah publish bearer doc
• Hannah set up dedicated meetings on big topics (Andrea away next meeting)
• Hannah to follow up with CERN OpenShift about letsencrypt issue
• Hannah to follow up about getting grid certificates for Openshift applications