WLCG AuthZ Meeting




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


  • 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
There are minutes attached to this event. Show them.
    • 16:00 16:20
      OSG Perspective 20m
      Speaker: Brian Paul Bockelman (University of Nebraska Lincoln (US))
    • 16:20 16:40
      INDIGO 20m
      Speaker: Andrea Ceccanti
    • 16:40 17:00
      FIM Considerations 20m

      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?

      Speaker: Hannah Short (CERN)