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".
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.
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
curlcommand: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$PATHis 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/atlasthen the following scopes have the following consequences:storage.read:/authorises reading of all files in/data/atlasstorage.create:/home/paulauthorises 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:/publicwould work on two storage systems even if one storage service places all ATLAS data under/pnfs/example.org/data/atlasand 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
$PATHin$AUTHZ:$PATHscopes) 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.