WLCG AuthZ Call - Fermilab Qs

Tuesday Jan 28, 2020, 4:00 PM → 5:00 PM Europe/Zurich

31/S-027 (CERN)

Proposed agenda: 

Fermilab is finalising the federated identity architecture and has a few questions that are worth discussing with the group in order to check that we are aligned, and perhaps to raise issues we may have overlooked.

In particular: 
• Token type,  ID+groups vs Access+groups?
• Client user interface. Command-line based solutions as opposed to web-based solution.
• Token renewal interface. how does the client handles the renewal.  
• Specifying audience for a token
• Group membership plugins that we need to provide to SciToken. 

Notes Fermilab AuthZ Qs, 28th Feb
Attendees: Andrea, Burt, Hannah, Irwin, Jenny, Jim, Julie, Mine, Mischa, Tanya, Ken, Maarten, Tom, Paul, Dave

• Token type,  ID+groups vs Access+groups? (Currently planning to use groups)
- For WLCG not one but both (see spec at https://zenodo.org/record/3460258#.XjBOBS2ZM1I)
- Groups can be in both
- ID tokens are OIDC specific, meant to be consumed by client that made the request
- Access tokens are an authorisation credential, can be sent around for authorisation purposes (can also be exchanged)
- In case of both CERN and WLCG, a single token issuer produces and signs both the access and ID tokens
- 2 different tokens are produced, this is important since the standard describes 2 separate tokens and downstream libraries may use them in different ways
- Access token intended to be (or at least sometimes are) opaque and used to access User Info endpoint if additional Identity information needed. In WLCG we use a JWT as an access token, partially to allow for distributed validation (since they are signed by the issuer and clients should periodically query the issuer public keys)
- Example flow

1. User logs in through CERN SSO, CERN SSO sends ID and Access token with CERN information to WLCG Token Issuer
2. WLCG Token Issuer takes that information, adds WLCG specific group/capability information, produces and signs new Access and ID tokens
3. Downstream client/service/resource receives tokens from WLCG Issuer, validates token and uses it for authorisation

• Client user interface. Command-line based solutions as opposed to web-based solution.
- Fermilab looking at portal based + OIDC Agent (with device code flow) 
- Ideally do in a way that is transparent to users, although this is tricky with CLI
- OIDC Agent seems to be the way to go. You do one "painful" authentication (browser), then a refresh token is stored. Dave looking at allowing kerberos authentication to OIDC Agent (to make it transparent to those with a Fermilab account) 
- Plan to distribute pre-configured clients? Not yet (though OIDC agent is available on e.g. home brew and easily configured) 
- Fermilab experiencing issues using OIDC agent with CiLogon (first time), particularly r.e. integrating clients 
- INFN WLCG Token Issuer can be used, can register web or command line clients. There is a test application that can be used to retrieve tokens for testing purposes

• Token renewal interface. how does the client handle the renewal.  
- Can use Condor credmon for renewal (Condor keeps the Refresh token and can request new access tokens as needed)
- Anticipated that multiple services will handle their own Refresh tokens and token renewal
- Refresh tokens must not leave the client that requested it (according to spec)
- E.g. user gives a token to Rucio, Rucio exchanges the token for other clients. There is a delegation of credentials
- Inner workings should be hidden by VO tools
- Scientific portal at the border of the workflow should manage the complexity of Refresh. Token exchange will be needed for intermediate tokens 
- TODO - we should make some diagrams of realistic workflows... (apparently some might exist, check with Maarten)

• Specifying audience for a token
- If we get a token for one service we cannot use it for a different one (have to exchange)
- Should we use a very generic audience? E.g. Fermilab audience
- Negatives: trying to limit power of a single token
- Positives: fewer token exchange passes required
- We can be entirely flexible, should balance risk and usability
- SciTokens library understands audience (including generic WLCG audience)
- Services/clients must understand audience
- (OIDC agent did not support audience until recently)

• Group membership plugins that we need to provide to SciToken. 
- Want to be able to parse group membership info but currently not supported by libraries
- Can we collaborate here?
- In theory shouldn't be more complicated than many standard libraries that allow you to extract the contents of a JWT 
- Mapping activity between groups and local users could provide opportunity for collaboration (currently have multiple services doing this)
- Also require a mapping between user in token and local user (currently no common approach)