You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Resource owners can view and modify (here: cancel, possibly delete, see Consider adding additional API operations #167) task resources and update permissions for these resources other users
Resource maintainers can view and modify task resources, but they cannot update permissions
Resource owners can only view task resources
Service roles (administrators) are for the entire service, whereas resource roles (owners, administrators, viewers) are resource-specific
Members of pre-configured user groups (from JWT claims) can trigger task runs (POST /tasks); upon triggering a task run, they automatically become an owner of the created resource
Members of pre-configured user groups can view the service info (``GET /service-info`)
The text was updated successfully, but these errors were encountered:
I have talked to @Rahuljagwani yesterday, who is also implementing a FOCA app. He had given this issue a higher priority, where he would address it before implementing any of the controllers. I think that is a very good idea, because it means that when implementing the controllers, auth-related code (checks for 401, 403) can already be implemented.
On the other hand, it may not be trivial to get this right, and if it turns out to be very difficult, it shouldn't block other issues and should be resolved side-by-side with the first controllers. Please discuss with @Rahuljagwani and @kushagra189 in channel #aai on Slack.
Use FOCA's PyCasbin support to set up rules for access control.
Briefly, the following behavior would be desirable:
POST /tasks
); upon triggering a task run, they automatically become an owner of the created resourceThe text was updated successfully, but these errors were encountered: