multiVO IAM storage compatibility

[marianne013]

Hi All,

Following successfully enabling tokens with storage claims for one of the
WLCG experiments we wanted to investigate setting up storage tokens for one
or more communities on our multi-VO IAM server. We currently distinguish
between the communities using top-level groups in IAM.

At first we looked at creating storage scopes that always contained a
top-level path in claim, e.g. storage.create:/myvo1 or
storage.create:/myvo2 . The problem with doing that naively was that having
access to storage.create:/myvo1 would also allow a user to request any
path, even ones above /myvo1. We then found the documentation about how to
write a policy,
https://indigo-iam.github.io/v/v1.10.2/docs/reference/api/scope-policy-api/
but this does not appear to have any "friendly" interface (yet?).
Ultimately the problem with this approach is that we have to ask storage
admins to trust tokens from the root level of their storage on the promise
the IAM tokens will always contain the correct VO. This seems too risky.

We then looked at whether a token with both a storage.create:/ and
wlcg.groups:/myvo claims could be restricted to a specific path on the
storage server. We tried this on dCache but it appeared not to be possible:
The root path for a token is keyed entirely by issuer and no other values,
precluding the possibility of a multi-VO IAM server. It's possible to do
some mappings with groups, but it also fails if the token contains more
than one VO (there is no real consideration for the first group being the
"primary").

After discussing a related issue (VO name mappings) with an FTS developer,
we learnt that there is discussion about including a new VO claim in the
tokens. I don't know if there is some details on how that would be
implemented? It'd be nice if we could have a per-VO issuer endpoint (e.g.
https://myiam.whatever/myvo1 or /myvo2 ) so that the storage providers can
map that to VO root paths without any changes in the storage software. Is
anything like that planned? Maybe there is otherwise another approach that we could try
that we're not aware of?

Daniela & Simon @sfayer