- Assume that (at least physics) workflows all go through a workflow manager
- Sven: make sure that direct submission is not possible in that case
- Having a refresh token on the WFMS is not ideal fpr several reasons
- Petr: too many token requests to IAM (believe that it cannot handle the throughput)
- Luna: only know if IAM is available at the point when you want to refresh (at that point it's too late)
- No list of trusted token issuers permitted on the grid. This is done by the experiment publishing which issuers it uses.
- What should an issuer need to do to get on this list? Several policies.
- Luna: Such a list could also be used for revocation? Revocation of an entire issuer (would require a semi automatic way for software to read the list)
- Token issuer can effectively block itself by stopping publishing its JWKs
- Mischa: Suggestion that JWKs be hosted separately to the issuer - benefit to security as otherwise JWKs would be compromised at the same time the issuer compromised
- Maarten: Brian B has also suggested a CDN
- Mischa: SciTokens puts them in github
- There should eventually be 1 token issuer per VO plus probably issuers for WFMS
- Several solutions proposed for issue of how to do tokens for aynchronous workflows
- Very long tokens (not ideal for security)
- Local token issuers for the WFMS
- Could you have a future token? No, can't know when a job will run
- FTS = 3rd party copy. Flow for writing also requires reading at the end to make sure it worked fine.
- Identity of DDM is used
- Some difference of opinion on whether an individual user could be blocked inside a DDM or WFMS
- DavidC: for central suspension we need to be able to tell all token issuers not to issue for a particular user
- Marcus: one way would to have long lived but revocable access tokens
- This can be expensive and increase load on the issuer (if the same process)
- WFMS issuers should be constrained on audience, scope etc to mitigate risk
- In WFMS we are talking 200K running jobs. Status sent every few minutes, need a valid access token.
- If the compute node is talking back to WFMS every 10 minutes why can't it do a refresh flow at the same time?
- Could refresh tokens not be stored in the data base? Perhaps with signing, but this is not commonly done
- Enrico: shouldn't this be a client credential rather than a refresh token? Possibly the wrong workflow. Client credential could be passed around the infrastructure and used wen required to get an access token.
- Whatever gets put onto the grid needs to have a finite lifetime (client credentials current don't)
- One of the initial aims was to use standard solutions - but perhaps we've done all we can and after a certain point within the infrastructure we will have to do our own thing
- If we are doing something proprietary, how does that affect downstream parties (e.g. sites or EOSC compute or cloud). If we are non standard we will potentially lose them.
- It is still not clear exactly what performance would be required of INDIGO IAM (and by when) to avoid experiments doing workarounds
- We should escalate things to the OIDC Federation where possible to make it part of the standard
- We have to GUT working group to try and get to a unified OIDC standard, which should help integration
- Trying to extended the standard may actually help as additional expertise would join
- What would be out of the standard spec? Spec is very flexible
- Access token revocation not done at the issuer
- How is middleware defining who to trust? Manually adding it to their config
- Anyone creating a token issuer should be aware of what policies it should follow
- Raise github issue to externalise JWK endpoint in the well-known endpoint? for several reasons:
- Don't rely on IAM to be up to validate the tokens
- Can block an issuer without the input of the issuer
- However, this does shift the risk to wherever the JWKs are hosted
- or use RPMs for this?
- What performance needed for INDIGO IAM? Perhaps we can make this possible, collaborate with SKA ? Separate low throughput attribute authority from high throughput access token issuer
- This is fundamentally a cost benefit analysis, with experiments more likely (in some cases) to trust issuers that they run themselves
Actions
- DavidG DaveK Hannah (and others?): Write a page of what policies are required for a token issuer and share with TTT working group
- Petr/Maarten: provide required performance for IAM (potentially for a few models) and a timeframe for Berk/Enrico to analse faesibility
"Thank god X.509 is still there" - M L
