Participants: David C, Sven, Linda, Julie, Hannah, Mischa, Maarten, Jim, Jeny, Andrea, Petr, Tom, Romain, DaveD, Federica, Brian, Enrico, DaveK, Jeff, James
Notes:
- Overriding security concern is traceability i.e. tracking activity. Made harder with dynamic environment
- User activity traceability
- Split traceability (pilots hide information from sites, VO and site must collaborate)
- Opaque tokens typically have randomly generated strings. We are really thinking about privacy preserving tokens with non-human-readable subjects
- Token issuer
- Tokens contain history of issuers and accrue history (how can we get at this data)
- Central suspension
- We are missing site level blocking for tokens (Argus)
- Possibly with short lived tokens we are less exposed to risk, if user is blocked centrally then fairly quickly cannot perform actions
- VO level token blocking would be equivalent of suspending DN at the VO level (but works faster).
- However, there is no cross-VO blocking (which sometimes worked for X.509)
- Can we purge currently running jobs? This is a secondary activity.
- Central suspension = user not able to get more access tokens
- Have not been incidents that required immediate purging of jobs. Such tools may need to be tweaked for token based infrastructure.
- Even big sites always had problems blocking users, was very over-engineered. Critical that suspension in new model is simple
- Much stronger choke point at VO level
- Suggestion that security team able to block at each VO's IAM instance
- When user suspended, token issuer stops issuing new access tokens to them
- Do we need JWT security event tokens?
- If spanning multiple federations, how do we tell others that an identity should be suspended?
- Might be a secondary question, focus on blocking for WLCG
- What done in OSG?
- Rely on VO's ability to handle users
- Eventually may block the full VO if response is inadequate
- Focus on good procedures rather than tooling
- Relationships disappear with people, need to design procedures that allow new people to execute.
- Jeny proposes separate security tabletop exercises (traceability & security incident)
- Call out to the different security teams to document current security capabilities to be able to adjust expectations with tokens (whilst workflows are being finalised)
- Aim to have multiple tabletops (DavidC happy to organise)
- An API for blocking may be useful, avoid having additional admins in IAM instances & going through training. Could just pick up a list of blocked user IDs from a trusted endpoint.
- Work ongoing for workflows (CEs and delegated transfers), sensible to have a tabletop when ready and only then write an API
- Previously just put DN in a ban list and it happened (sometimes), do we introduce more conversations in the new model
- VOs and sites always had the final word (could always be overwritten)
- VOs running with few identities risk having the entire VO switched off
- HTCondor Audience Values
- There is an RFC https://datatracker.ietf.org/doc/html/rfc8707#section-2
- We provided guidance in the profile, maybe the profile is not clear enough (i.e. URI) https://zenodo.org/record/3460258#.YVXBji0RoUF
- IAM deployments
- Aiming for Monday but trying to do things properly, aiming for common configuration before deploying instances for ALICE and LHCb
Don't forget the token transition workshop coming up: https://opensciencegrid.org/events/Token-Transition-Workshop/ . It's a touch OSG-centric but of course, all you folks are welcome!
Also please don't forget WoTBAn&Az 2021 (https://opensciencegrid.org/events/2021-NSF-Cybersecurity-Summit-Workshop/) the following Monday. We'll be posting the schedule (including the WLCG AuthZ presentation) at https://sciauth.org/workshop/ soon.
There are minutes attached to this event.
Show them.
