WLCG AuthZ Meeting

Wednesday 11 Oct 2017, 16:00 → 17:00 Europe/Zurich

Notes:

OSG

• Brian’s slides on SciToken https://indico.cern.ch/event/578991/contributions/2746656/attachments/1538987/2412485/SciTokens-GDB-Oct-2017.pdf
• Some difference between US and EU certificate provisioning, in US the VO plays a larger role than the institution 
• Believes authentication best handled by VO
• OSG has a small number of large VOs ~10
• OSG trusts VO, who trusts user -> user only exists in context of VO
• x509 is unnecessarily complicated
• Doesn’t want to deal with authentication, should be outsourced to VOs, like it when federated identities are used
• Don’t want proxy commands anywhere, should be automated
• Privacy preservation impacts traceability
• Would like to see WLCG providing 
• Certificate federation, VOs do not provide identity (independently provision)

INDIGO

• Very similar approach, token based access
• Project now over
• Key requirement was to discover how to provide strong support for federation AAI and social logins
• Account linking behind the scenes, just 1 INDIGO identity
• Delegation problem addressed
• Token translation to legacy software provided
• Uses OpenID Connect, popular in web env. works for e.g. open stack, apache, kubernetes
• OAuth token issued to clients when they need to access a resource, also OAuth tokens for delegation (but require going beyond the standards if multiple steps of delegation)
• Tokens are signed JWT - very easy to integrate
• Likely have 1 logical service per VO, so can share per VO
• Provisioning handled by SCIM standard, REST API
• Integrating Argus (due now) - extract authN and authZ from tokens
• Production ready AAI solutions in EOSC-Hub product portfolio

Questions and Answers:

• Regarding OSG no longer distributing VOMS-Admin software, not downloading user DNs from VOMS
  • ARGUS doesn’t depend on VOMS-Admin
  • Downloading and mapping is for services that don’t implement the VOMS parsing and validation correctly, but ideally we do not need it
  • Most middleware does not need the endpoint
  • EU Data Directive doesn’t necessarily mean no data sharing, must be managed and reasonable
• OSG is happy to accept credentials from WLCG, they trust the VO to supply them correctly. Which tokens (at HTTP layer)
  • Bearer tokens (SciTokens)
  • Macaroons
• Where does VOMS fit in?
  • Historically have never checked VOMS directly, checked against cached list
  • Now just check that it’s “fine” and map based on VOMS credentials (e.g. which role is required?)
• How would a change impact OSG vs EGI?
  • EGI many more VOs
  • VOs play slightly different roles

16:00 → 16:20 OSG Perspective

Speaker: Brian Paul Bockelman (University of Nebraska Lincoln (US))

OSG-AAI-WG.pdf

16:20 → 16:40 INDIGO

Speaker: Andrea Ceccanti

INDIGO-AAI-October-2017.pdf

16:40 → 17:00 FIM Considerations

FIM Discussion Points:
- How can we enable membership requests based on federated credentials?
- What is a suitable source of membership roles & groups? Does it need to change? (VOMS, e-groups, User Office, COManage etc)
-Acceptable LoA of federated credentials?
-Acceptable trust in IdP (e.g. Sirtfi)?
-Identity vetting process integration? (Between User Office & AA)
-Account transfer between federated credentials (home organisation changes)?
-What needs to change for services to accept federated credentials?
-Translation services?
-Move non web services behind web portals?
-CLI possibilities?
-Can we remove the need for certificates in the hands of the -user - or make it transparent?
-How can we block users?
-Blocking at the authentication stage?
-Real-time blocking?
-Blocking long lived access tokens (certificates, OAuth tokens, etc)?
-How can access rights (roles/groups) for a user be queried?
-What can we expect of users in addition to web based AuthN?
-Certificate management?
-SSH Key management?
-Other?

Speaker: Hannah Short (CERN)