No discussion on how to map the scope path to request path

[paulmillar]

Authorisation is the process of deciding whether or not to allow a request. On storage systems, requests typically involve a path. This is the "request path".

For example, the curl command:

curl https://storage.example.org/my-VO/reference-data/some-data.root

instructs the client machine to make an HTTP GET request. The request path is /my-VO/reference-data/some-data.root.

The storage AuthZ scopes (storage.read, storage.create, etc) MUST contain a path. These paths are expressed in the scope in the form $AUTHZ:$PATH (e.g., storage.read:/foo). This $PATH is the scope path.

However, the document seems to contain no discussion on how a scope's path relates to request paths.

I think relationship between a scope's path and request paths is a critical piece of information, as authorisation statements only makes sense in the context of requests made by a client.

For example, the following is the scheme adopted by dCache:

Each VO (i.e., each issuer) has a corresponding authorisation base path. This is the VO's base path: the path under which the VO should write data.. All AuthZ scope paths are resolved relative to the issuer's AuthZ base path.

For example, if a dCache is configured so that the AuthZ base path for the ATLAS VO issuer is /data/atlas then the following scopes have the following consequences:

• storage.read:/ authorises reading of all files in /data/atlas
• storage.create:/home/paul authorises creating (non-destructively) of files and directories in /data/atlas/home/paul.

I think this approach makes sense. It allows the OP to issue tokens that are independent of the individual storage system, provided the storage system provides storage resources for a VO under a single directory and provided the VO has a common data-placement policy.

For example, an ATLAS token with storage.read:/public would work on two storage systems even if one storage service places all ATLAS data under /pnfs/example.org/data/atlas and another storage service places ATLAS data under /vos/atlas/data.

However, this is not the only solution: there are other approaches with different trade-offs.

To promote interoperability, I think the document should at least acknowledge that there is a question on how to map scope paths (the $PATH in $AUTHZ:$PATH scopes) to the corresponding request paths when an agent makes a request involving that scope's token.

Ideally, the document would describe a standard approach for doing this mapping.