Provide examples of how an "authorized area" is interpreted for HTTP … #45
Conversation
…requests In #34, @paulmillar pointed out there's no explicit mention of how to authorize a request resource with a given storage scope. This is my first draft at an attempt for some examples and expansion of what was previously written about handling an "authorized area".
| @@ -497,6 +497,17 @@ When groups are asserted (in an Access Token or ID Token, or both), it is a stat | |||
|
|
|||
| When a capability is asserted (only in Access Tokens), it is relative to the VO’s coarse-grained authorization; the resource only maps the token to a VO, then uses the capabilities in the token for fine-grained authorization within the VO’s authorized area. In this way, the VO, not the resource, manages the authorizations within its area. | |||
|
|
|||
| For a storage resource, the "authorized area" is typically implemented as a set of one or more request prefixes assigned to a VO, corresponding to file paths on a filesystem. Requests should be authorized by evaluating the scopes within the context of these prefixes. For example, suppose a resource server `https://storage.site.org` has associated an issuer `https://vo.example.com` with prefix `/vo`. Then, a token with scopes `storage.read:/ storage.create:/stageout` can authorize: | |||
There was a problem hiding this comment.
This example clarifies the current approach but I think it hides a strong assumption that a strict relationship between one issuer (https://vo.example.com) and a logical "access-point" (/vo) exists. Within StoRM deployments there are a lot of cases where the same VO (or issuer) owns different logical paths, so there you could have the following pairs, for example:
https://vo.example.comand/vo-diskhttps://vo.example.comand/vo-tape
This is the easiest example: having two different logical endpoints for disk and tape storage areas, which cannot be the same due to the fact that each logical path has a physical path behind. That strict relationship between issuer and logical access-point, leads to the fact that potentially the same token can authorize actions on different logical path. There's no information on the access token that univocally identifies the correct logical path between /vo-disk or /vo-tape. It's completely a provider decision. Or it's ignored and the token is valid on both of them.
So, referring to your example, what about including the logical path /vo into scope path? E.g. The logical path /vo/sample_file1 can be authorized by storage.read:/vo, the logical path /vo/stageout/sample_file2 can be authorized by storage.read:/vo/stageout, and so on. And there's obviously a difference between storage.read:/vo-disk/file1 and storage.read:/vo-tape/file1. In this case, scope's path univocally identifies a physical path and really simplifies the authorization logic by having an identical requested URL's path that matches it.
What do you think about this?
There was a problem hiding this comment.
Ciao Enrico,
would it be possible to have such "/vo-disk" and "/vo-tape" directories replaced with symlinks pointing to real directories located under a common VO root directory (e.g. "/vo") to which a token gets mapped? Like this:
/vo-disk -> /vo/vo-disk
/vo-tape -> /vo/vo-tape
It would allow token requests to refer to "/", "/vo-disk" or "/vo-tape" as needed, all interpreted relative to the single VO area root directory.
While the VO keeps using its historic prefixes, pollution of "/vo" can be avoided by making it read-only.
OTOH, the VO might be interested in a more elaborate configuration, which would allow it to phase out its use of the prefix for the more frequently used disk area:
/vo-disk -> /vo/vo-disk -> .
In practice it might be easier to have the symlinks point in the other direction instead, though:
/vo/vo-disk -> /vo-disk
/vo/vo-tape -> /vo-tape
In either case, the layout could remain backward compatible for as long as needed, while allowing the VO to take advantage of configuration enhancements that are available with tokens, e.g. permitted by having the same namespace across SEs at different sites.
What do you think?
There was a problem hiding this comment.
Ciao @enricovianello @giacomini,
does the PR at least describe what StoRM currently implements?
…requests
In #34, @paulmillar pointed out there's no explicit mention of how to authorize a request resource with a given storage scope.
This is my first draft at an attempt for some examples and expansion of what was previously written about handling an "authorized area".