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