Duplicating Scope policies between IAMs?

[hannahshort]

Hello,

I had a question from a service manager who anticipates that they will trust multiple IAM token issuers. They would like to use capabilities for specific paths, e.g.

storage.write:/user/h/hshort storage.read:/mygroup

This authorisation logic and knowledge is known by the service rather than by IAM at the moment. If we wanted to add it to IAM it would imply adding fairly complicated scope policies to multiple IAM instances. Has anyone done this (this = keeping scope policies consistent between IAM instances, possibly involving another service to keep policies in synch)?

As an alternative we would need to have a blanket policy to permit any scope requests from this particular client. Is this a standard workflow?

Thanks for your input!

[vokac]

For each token issuer there is /issuer-root SE configuration and I would expect that normal configuration will be something like

https://atlas-auth.web.cern.ch/ /atlas
https://cms-auth.web.cern.ch/ /cms
https://cilogon.org/dune /dune
...

That means there is no general way to grant access to the data between different VOs when client use tokens (I did not check how e.g. dCache symlinks works with tokens or similar mechanisms in xroot plugin that allows you to map namespace structure). Giving ATLAS user token with storage.modify:/ scope only grant access to the storage /atlas sub-directory as configured for ATLAS token issuer.

Same behavior currently apply to the user home directories, because I'm not aware of any special treatment of personal storage areas (home directories are mentioned in the WLCG JWT profile, but to be honest description of expected behavior is not completely clear to me). This means people in multiple VO gets different home directory per-VO and they'll not be able to move data between their different home directories. You could also configure different "doors" for home directories with shared /issuer-root and than it would be possible to access personal home directory with any token from supported issuers, but in this case you rely that all issuers share same usernames for same people ... e.g. in case of CERN IAM instances any VO-Admin could than create local account with privileges to destroy data in the user home directories of any competing experiments (fortunately EOS/XRootD doesn't / can't strictly implement what's written in WLCG JWT profile so most probably this SE implementation can't be easily configured in this dangerour way).

I have to admit I did not completely get why you mentioned IAM policies. In case we decide to support home directories with tokens, we'll need per-user policy that looks like: "user hshort should be able to get storage.*:/user/h/hshort token", but for token issued by ATLAS IAM this will be mapped to the basepath /atlas/user/h/hshort. XRootD scitoken configuration is quite flexible so it should be possible to use this token with /user/h/hshort (may be with different EOS hostname / doors), but EOS admins have to be careful not to give VO-Admis too much power over home directories of users that are just members of different VO.