WLCG AuthZ Call

Europe/Zurich
Description

Proposed agenda: 

  • Announcements/Info
  • Discussions:
    • User linking (X.509 and OAuth) in future - Julia, Alessandro, Panos etc. 
      • The main question discussed at the WLCG Ops Coordination is the primary source of info for  secondary accounts.
    • Capability Sets
      •  https://github.com/WLCG-AuthZ-WG/common-jwt-profile/pull/10
      • Debate on mailing list about what should happen if unauthorised scopes are rejected
        • Proposal from Brian's recollection : 

          1.  The token issuer MAY include a wlcg.capabiltyset claim in the resulting token with a string-formatted list of capabilitysets included in the token.
          2.  If the requester is not authorized to have a given capabilitiyset, the token issuer MAY deny the entire token request.
          3.  For (2), if the token issuer issues the token anyway, it MUST set the wlcg.capabiilityset claim with the requested capabilities that were authorized (or empty string if none).

        • This is quite a few MAYs and perhaps not very helpful to clients. However, in cases like Vault, when they don't really know what authorisation is needed it could be useful to get the token anyway. On the flip side, better to fail right away to help debugging rather than propagating a token that may fail later.

        • OAuth RFC says that scope requests may be ignored but doesn't forbid failing with an error 

      • Dave to add examples & motivation
    • Standardisation of CE capability requirements
    • MyProxy Equivalent for tokens
    •  
    • id token claim for use by vault with kerberos (Dave, Andrea, Hannah)

Zoom meeting:

Please ensure you are signed up to project-lcg-authz@cern.ch to receive the meeting password!

Join Zoom Meeting
https://cern.zoom.us/j/94718857994

Meeting ID: 947 1885 7994
Password: <see email>
One tap mobile
+41432107042,,94718857994# Switzerland
+41432107108,,94718857994# Switzerland

Dial by your location
        +41 43 210 70 42 Switzerland
        +41 43 210 71 08 Switzerland
        +41 31 528 09 88 Switzerland
        +33 1 7037 9729 France
        +33 7 5678 4048 France
        +33 1 7037 2246 France
Meeting ID: 947 1885 7994
Find your local number: https://cern.zoom.us/u/abjrVtLBu4

Join by SIP
94718857994@188.184.85.92
94718857994@188.184.89.188

Join by H.323
188.184.85.92
188.184.89.188
Meeting ID: 947 1885 7994
Password: <see email>

Participants: Julia, Andrea, DaveD, Enrico, Federica, Irwin, Jeny, Jim, Julie, Maarten, Mine, Marcelo, Mischa, Panos, Enrico, Jeffrey, Linda

Notes:

  • User mapping between accounts (e.g. CERN login and X.509)
    • Issue is mapping between grid identities and CERN accounts (for which user type?)
      • Particularly relevant for EOS
      • Users will need to access EOS from both Grid workflows and logging in directly to EOS/Cernbox
      • EOS will need to be able to map X.509 and cern logins to the same user
    • Existing X.509 certificates will be pushed to IAM
    • Users also have the possibility to link further certificates
    • Information about all identifiers for a user is available via IAM API
    • Already being used by ESCAPE research community
    • Any service that needs this information will need to be a registered client in IAM with certain permissions
      • They will get a clientID and secret that they can use indefinitely
    • See https://indigo-iam.github.io/docs/v/current/user-guide/api/scim-api.html
    • Is this (the IAM API returning linked accounts for users) sufficiently generic elsewhere?
      • Fermilab experiments are using CiLogon
      • Fermilab users at CERN experiments will be able to link certs and have a CERN account
      • If there's a hybrid model without a single IdP (e.g. DUNE have both CERN and Fermilab) we might need to check further
  • VOMS migration being tested
    • IAM requires a unique email for users
    • Merging is not a safe choice
    • For ATLAS some information would be overwritten, accounts have the same email but different nicknames
    • Could alternatively take the first account as the correct one and ask VO Admin to check the other details
      • ATLAS & CMS each have about 80 accounts that share an email
    • Alternative (requires development) is to support secondary and service accounts
    • Having the concept of service & secondary accounts in IAM may be nice
  • Fail handling on scope requests
    • Capability sets should be a set of essential (not optional) capabilities -> if they are not all authorised then the request should fail
    • If a capabilityset is granted it MUST be the whole set. If it is not granted an error SHOULD be returned (with a useful message).
    • This is kind of re-implementing the VO roles
    • We should be consistent between groups and capabilitysets 

Actions:

  • Andrea add a Jira ticket to consider service and secondary accounts in IAM
  • Andrea produce list of duplicate accounts for CMS, to be passed to VO Admin to see whether many of them could be de-dup'd 
  • Dave to add some clarification text to the PRs
  • Hannah to add continued discussion to next time's agenda
  • Maarten to clarify whether the timeline under discussion only affects CMS or the four LHC VOs?
There are minutes attached to this event. Show them.
    • 15:05 15:35
      X.509 and Token linking 30m