Compliance tests

• Improvements in recent compliance tests results
  • can we keep slightly longer history, e.g. a month
• RAL testbed configuration updated and passing all tests except storage.create that doesn't work by design in XRootD 4.4.x
• New XRootD 5.5rc1 comes with correct storage.create implementation, but returns wrong (default) HTTP 500 error issue#1752
  • compliance tests expect HTTP 403 but gets HTTP 500 Internal Server Error
  • patches already exists issue#1763 and they should be released with XRootD 5.5
  • necessary to be able to pass compliance tests with XRootD, Echo, EOS

Transfers with tokens and X.509

Basic informations in the July 6 BDT Notes, non-official configuration ideas for dCache, XRootD

• Is it possible to avoid using ACLs with dCache? Example of minimalist per-experiment configuration?
• What would be the StoRM configuration for normal experiment storage configuration?
• EOSATLAS already use ACLs (at least for atlasscratchdisk) to give access to normal users and also Rucio with production role

It seems to me storage either have everything mapped to one identity + access restriction for given path configuration (e.g. simple XRootD configuration) or in case VO groups/roles are mapped to different storage identities than ACLs are necessary to give right access permissions to multiple identities.

Common configuration

This WLCG experiment storage access configuration requirements moved to the WLCG AuthZ documentation.

ATLAS

Rucio file replication with FTS always use production role when writing files in the "rucio" subdirectory and while deleting files. For jobs using rucio upload the identity used while writing files differs for production (/atlas/Role=production identity) and analysis jobs (/atlas identity). Also user can store own files with rucio upload and normal /atlas identity.

• /basepath/atlas ... read only for /atlas group
• /basepath/atlas/atlasscratchdisk ... inheritable read for /atlas and write for /atlas + /atlas/Role=production
• /basepath/atlas/atlasdatadisk ... inheritable read for /atlas and write for role /atlas/Role=production
• /basepath/atlas/atlaslocalgroupdisk ... inheritable read for /atlas and write for group /atlas/country_code + /atlas/Role=production

All files can be read with basic /atlas identity.

CMS

• /basepath/cms ... everything readable by /cms identity
• /basepath/cms/{data,mc,...} ... write for role /cms/Role=production
• /basepath/cms/group ... write for role /cms/Role=priorityuser
• /basepath/cms/group/rucio ... write for role /cms/Role=production
• /basepath/cms/user ... only for local users from same home institute (may even provide per-user access permissions)

ALICE

• easy, everything is already mapped to just one account / no access with X.509

LHCb

• /basepath/lhcb ... readable/writeable by production user
• /basepath/lhcb/user ... writeable for normal users

Required storage features

• dCache - (efficient) recursive ACL updates

Action point

• Petr: add these details in the WLCG AuthZ github pages and ask via TPC mailing list (+ add developers) to contribute recommended per-experiment configuration for each storage type

IAM Scope Policies

• don't try to test this functionality if you are IAM administrator - admin account gives you "unexpected" privileges with tokens
• impossible to define scope policies for clients that are not associated with user accounts(?)
• restrict client access to the specific path, e.g. /atlasdatadisk
• defined policy must end with a slash, e.g. storage.create:/atlasdatadisk/
  • otherwise client gets access also to the arbitrary path in a format /atlasdatadiskwhatever
• anybody plans to use this functionality for storage.*:/home/username/(?)
  • performance with thousands of policies defined in IAM(?)
  • not completely crazy idea, but we have to think more about this use-case
    • may be not an performance issue, but managing thousands of rules is also not optimal
    • may be we'll need support for some kind of templates in policy definition
  • its also a question if user "home" directory permission should be enforced by IAM or storage should just simply apply token identity mapping (e.g. as done by CERN EOS)

Action point:

• Petr: create WLCG JWT Profile github issue to make clear behavior without trailing slash in the storage.*:/path scope