WLCG AuthZ Call
Proposed agenda:
- Feedback on CMS IAM (continue)
- Client Tools Technical Investigation
- Big picture discussions to have
- Should we be relying on the CERN IdP? Pros vs Cons
- Audience guidance from profile doc https://github.com/WLCG-AuthZ-WG/CommonJWTProfile/pull/3
- Mapping user accounts in a token infrastructure
- Guidance on service owners choosing between WLCG IAMs or CERN IdP
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, Brian, DaveD, DaveK, Tom, Ian, Jeny, Julie, Marco, Maarten, Irwin, Liz, Linda, Will
Apologies: Andrea
Notes:
- htgettoken & Vault set up, configured for WLCG and CMS token issuers (centos7) set up by DaveD
- Dave did a demo
- ``htgettoken -a fermicloud346.fnal.gov`` (the vault server)
- Defaults to WLCG IAM, launches browser (can specify target IdP as needed)
- Log in and authorise vault client
- Returns to terminal
- Saves credkey (email address, stored in ~/.config/htgettoken/credkey-default-default file, used for identifying where user's token is stored)
- Saves refresh token in vault
- Stores bearer token in /run/user/.../bt_... (as per our spec)
- Stores vault token in /tmp/vt_...
- Can run with -d (debug) flag
- Second time run, uses kerberos
- What about scopes? Where are they defined?
- Would have to be managed by the Vault admins
- Plan to submit PR to puppetlabs for Vault to allow requests to limit the scope
- What sort of error messages can come back?
- Kerberos - what needs to know your principal?
- Config includes config for ldap to check that user exists
- In oidc config can specify which claim becomes credkey "claim_mappings" and the user_claim as the vault index
- Security hole -> if someone can change their email to yours they can get your token
- Some concern about trying to align WLCG token content with local lab Kerberos
- Could be possible to write an ssh plugin for Vault authentication
- Same as scopes, we need to be able to specify the audience (for a particular endpoint or CE)
- How to set up? Maybe a vault configuration generator?
- May be the moment to just try it out and then come up with further requirements
Actions:
- Dave and Will to set up an instance at STFC and generate documentation during the process
- Others to try and set up htgettoken
- Hannah to follow up with Marcus about oidc-agent, don't want to duplicate effort
- Hannah to edit Client Tools Doc into reasonable shape. This will be a v0.1 that we will return to once we have more experience