WLCG AuthZ Call

Europe/Zurich
Description

Proposed agenda:

  1. Performance/scalability discussion
  2. Schema document comments https://docs.google.com/document/d/1cNm4nBl9ELhExwLxswpxLLNTuz8pT38-b_DewEyEWug/edit?usp=sharing 

Attendees: Andrea, Brian, David, Hannah, Ioannis, Jeny, Linda, Maarten, Nicolas, Linda

Apologies: Mischa

Notes:

  • Scalability
    • How can the service handle e.g.
      • Multiple concurrent token introspection queries?
      • Clients hammering service
    • Approximate numbers
      • Thousands of users (ATLAS estimate = 4000 in VOMS, but many are inactive)
      • Dozens of groups
      • Millions of tokens
    • Service needs to be designed in a scalable way
    • IAM has not yet done load testing at LCG scale but has on smaller scale
      • Growing number of refresh tokens in database needs to be contained
    • Andrea offered to run some scalability tests but WG must come up with precise guidelines, i.e. when to request refresh tokens
    • Q from Nicolas r.e. refresh token garbage collector - policy defined to 13 months
    • SciTokens, single core can produce 10,000 tokens per second so haven't revisited
      • Refresh token per user per sched d (? not sure how to spell)
      • Token renewed at 1/3 of lifetime (to allow failover twice)
      • Rate of about 3Hz for CMS users requesting new access token with refresh token
      • In a fine grained scenario this would go up
    • Also need to consider Usability of UI at scale, client and user management etc
    • EGI-Check-in, how many users? 1000 users, O(dozen) groups. Web service but also Openstack so refresh tokens are used
  • ARC should send us some feedback on actions for compute in the next few days
  • R.e. group requests, what should happen when a group does not exist for the user? How will groups be requested?
    • Allowed scopes for a client
    • Fail on user not entitled to scope?
  • Need separate discussions on
    • which CAs to use for clients and token issuers, significant usability issues with  trying to use IGTF CAs
    • behaviour when user not entitled to group requested in token
    • load testing
    • compute scopes
  • EGI-Check-in and IAM will collaborate on testing tools, e.g. Grinder framework python http://grinder.sourceforge.net/

Actions:

  • Working Group to start work on model of load testing over next few months
  • WG to discuss compute scopes after receiving feedback from ARC
  • @ALL to re-read and comment on the document
There are minutes attached to this event. Show them.
The agenda of this meeting is empty