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
• 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)