-
Notifications
You must be signed in to change notification settings - Fork 5
Open
Labels
Description
A token may contain a path to which the user is authorized. Currently, if the user tries to access a different path that the token allows, the dCache API error is returned. That may be a bit vague error like 403 - forbidden. A type in a path can be easily overlooked. A warning that the paths don't match would be user friendly.
Testing with a macaroon with this path:
cid path:/users/subdirthatdoesntexist
Trying to view my home dir:
% ada/ada --tokenfile tokenfile_test.conf --list /users/onno
Error while getting information about '/users/onno':
{
"detail": "Forbidden",
"title": "Forbidden",
"status": "403"
}
ERROR: could not determine object type for '/users/onno'
Now, there are several token types.
- Macaroon with
cid path: - Macaroon with
cid root: - OIDC token with
storage.read:/subdir(an authorization token) - OIDC token without any
storage.*claim (a non-authorization token)
This is how we should validate them:
- The operation path (
/home/onno/subdir) should start with the token path (/home/onno). Need to think about trailing or double slashes. Please note that with a macaroon with path/home/onnoyou can also view/homeand even/. So either one should be a subset of the other. - We can't check this. dCache will prepend the operation path with the token path. Skip check and move on.
- We can't really check this. The internal dCache OIDC config determines how the
storage.read:/subdiris handled. In all cases that I'm aware of, the/subdirwill be prepended by dCache with a root path, like/groups/dteam. What we can check though is whether this token has astorage.readfor a read operation, astorage.writefor a write operation etc. - There is no path in the token so there is nothing to check.
Reactions are currently unavailable