Brian Paul Bockelman (University of Wisconsin Madison (US)), Maria Arsuaga Rios (CERN), Petr Vokac (Czech Technical University in Prague (CZ))

Topic: WLCG DOMA BDT Meeting (twiki)

Zoom Meeting ID
Petr Vokac
Useful links
Join via phone
Zoom URL
    • 1
    • 2
      Transfers with tokens
      Speaker: Francesco Giacomini (INFN CNAF)

      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
        • 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
    • 3
      Tape REST access
      Speaker: Mihai PATRASCOIU (CERN)
    • 4
      Packet marking
      Speakers: Marian Babik (CERN), Shawn Mc Kee (University of Michigan (US))

      SC22 is ongoing.  We have demos using packet marking in place.


      Dashboards at: 

      Nice article from InMon (SFlow monitoring company) at: https://blog.sflow.com/2022/11/scientific-network-tags-scitags.html


      Picture of posters (SciTags and NOTED) attached to indico.





    • 5
      WebDAV Error Message Improvement Project

      Discuss with experts improvements in the error messages produced by failed transfers.

      Speaker: Stephan Lammel (Fermi National Accelerator Lab. (US))
    • 6