WLCG JWT profile storage.* scope improvements (issue#21)

• Trying to find volunteer with experience writing standards to incorporate summary from issue#21
  • Finalize in next BDT meeting (pull request or invite people that could prepare standard update)
• Once we update profile
  • Add in compliance tests also tokens with trailing slash
    • with storage.{create,modify,read}:/foo/bar/ allow only directory operations on /foo/bar
    • clarify if storage.modify:/foo/bar/ can be used to remove /foo/bar file
      • with object storage it is probably possible to have file /foo/bar and also /foo/bar/baz
      • requirements in standard should not make implementation too complicated for storage that doesn't have real directories
  • Create tickets for SE implementations that doesn't pass new tests

Base path configuration for token issuer

• Few token related presentation from Rucio Workshop provided examples that signalize people are not fully aware how to correctly configure token issuer basepath
• Each storage that implements WLCG JWT profile allows to specify different basepath for each token issuer
  • storage.*:$PATH verification is applied relatively to this $PATH, e.g.
    • issuer basepath: /top/level/dir/for/VO/wlcg
    • wlcg token scope: storage.read:/foo/bar
      • allows user to read data from /top/level/dir/for/VO/wlcg/foo/bar
    • wlcg token scope: storage.read:/
      • no access to the /top/level/dir/for/VO/dteam
  • For storage shared by multiple VOs it doesn't make sense to set issuer basepath to "/"
    • Tokens from any VO would be able to access/destroy all data including other VOs
  • Normally basepath should be set to top level VO directory, e.g. when VO top level directory is in the storage root
    • issuer: https://wlcg.cloud.cnaf.infn.it/ ... basepath: /wlcg
    • issuer: https://atlas-auth.web.cern.ch/ ... basepath: /atlas
    • issuer: https://cms-auth.web.cern.ch/ ... basepath: /cms
    • issuer: https://cilogon.org/dune ... basepath: /dune
    • ...
  • Storage with VOs top level directories deeper (e.g. in /pnfs/example.com/home) would use this full path for issuer basepath (e.g. /pnfs/example.com/home/atlas)
    • Relative path in storage.*:$PATH scope allows us to define global IAM policies for storage paths, e.g.
      • ATLAS Rucio client can only get storage.*:/atlasdatadisk and storage.*:/atlasscratchdisk scopes in token
      • We need same namespace organization below top level VO directory used as a basepath for VO token issuer
• SE token issuer basepath configurations:
  • dCache - part of gplazma.scitoken.issuer / gplazma.oidc.provider 
  • StoRM - accessPoints(?)
  • XRootD - base_path in the libXrdAccSciTokens.so config file

Audience and global XRootD redirector (CMS AAA)

• CMS doesn't know which hostname to use for aud claim with their global XRootD redirector
  • Use redirector hostname + "CMS" in the aud claim
• Audience filter is global configuration for all our SE implementations
  • Common audience for storages shared by multiple VOs makes token validation by aud claim less useful
  • VOs can no longer assume that token stolen on SE1 can't ever be used on SE2 due to shared audience
  • Defining IAM policies on aud claim not possible
    • VOs can't prevent IAM to issue tokens with "CMS" generic audience
    • All VOs would be forced to define such audience policies when one decide not to follow WLCG JWT recommendation for aud content

Renaming uploaded files

• Supported with storage.create scope
• Problematic with some storage backends
  • Expensive operation that should be avoided
  • Needs to be considered for jobs without storage.modify privileges
    • ATLAS would like to have very limited set of services with storage.modify destructive permissions
    • Impossible to remove partially transferred files
    • File upload re-try => different filename and safe mechanism for registering failed transfers in Rucio for cleanup

Testing transfers with tokens

• How to include more users from experiments who would like to test tokens
  • Storage scopes are restricted and can be assigned only by IAM admin to the registered client
    • It is not possible to use storage.*:/$PATH restriction this way
  • Could we come with some scope policy (preferably same/similar for all experiments)
• Summary
  • Testing tokens with SE can be done using WLCG IAM tokens
    • No restriction for storage.* scopes when user ask to be member of xfer group
    • Storage administrators can configure their storage to support tokens from WLCG issuer
    • To tests different SE implementation there are testbeds that participate in WLCG compliance tests
  • For LHC experiments IAM administrators can specify who can get tokens with storage.* scope
    • storage.* scopes are restricted and no experiment currently configured scope policies in IAM for these scopes
    • CMS works with CNAF team to define storage.* scope policies in IAM
      • current IAM not flexible enough to meet all CMS requirements
      • storage areas accessible not only by Rucio