As our system grows, we need to ensure that users only have access to their resources for GET /tasks, GET /tasks/{task-id} and POST /tasks/{task-id}:cancel
Default access control setting would include these rules:
For creating a resource (i.e., POST /tasks), we would need to check if a given user is a member of a specific group. We would get this info from the Bearer token. A user creating a resource then becomes its "Owner".
Apart from viewing (GET endpoints) and modifying (POST /tasks/{task-id}:cancel) a resource, an "Owner" can also set the access roles for other users for that resource. So for example, if I create a resource and become its "Owner", I could give you an "Owner" role as well.
Other roles that *Owners" can assign to other users would be "Maintainer" and "Viewer" (the names of the roles can of course be different, maybe we can find better ones). "Maintainers" would be able to view and cancel jobs, but not modify access permissions. "Viewers" would only be able to view, i.e. get a detailed task info for the particular task, and have it returned to them as part of the list of all tasks.
Anyone without any of the roles could not even view the resource. But they may be able to create their own resources (if they are a member of the group).
Everyone should be able to access the service info, as long as they are authenticated, i.e., they send along a Bearer token - even if they are not part of the group that grants access to the task/resource creation endpoint.
As our system grows, we need to ensure that users only have access to their resources for
GET /tasks,GET /tasks/{task-id}andPOST /tasks/{task-id}:cancelDefault access control setting would include these rules:
For creating a resource (i.e.,
POST /tasks), we would need to check if a given user is a member of a specific group. We would get this info from the Bearer token. A user creating a resource then becomes its "Owner".Apart from viewing (
GETendpoints) and modifying (POST /tasks/{task-id}:cancel) a resource, an "Owner" can also set the access roles for other users for that resource. So for example, if I create a resource and become its "Owner", I could give you an "Owner" role as well.Other roles that *Owners" can assign to other users would be "Maintainer" and "Viewer" (the names of the roles can of course be different, maybe we can find better ones). "Maintainers" would be able to view and cancel jobs, but not modify access permissions. "Viewers" would only be able to view, i.e. get a detailed task info for the particular task, and have it returned to them as part of the list of all tasks.
Anyone without any of the roles could not even view the resource. But they may be able to create their own resources (if they are a member of the group).
Everyone should be able to access the service info, as long as they are authenticated, i.e., they send along a Bearer token - even if they are not part of the group that grants access to the task/resource creation endpoint.