WLCG AuthZ Call
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