Samenwerking Beheer Systeem ↣ Collaboration Management System
Apache License 2.0
3
stars
2
forks
source link
As an Org Admin, I want to generate an Org API token that is scoped to a set of Unit(s) so that a user with this token can use the Org API with Unit scoping permissions taken into account #1059
Orgs have Unit Managers that wish to use the Org API to programmatically manage COs. The Orgs wish to grant that power, but scoped to the Units and not for the whole Org.
Orgs want to give particular application owners the ability to manage COs. They want to do this without giving the application owner the ability to manage ALL COs within the org. They instead want to create Units within which the application owner would have the ability to manage COs using the Unit scoped token.
Org API Route
Description
Should be available to Unit Manager?
POST /api/collaborations/v1
Post a new collaboration
✅
DELETE /api/collaborations/v1/{co_identifier}
Delete collaboration
✅
GET /api/collaborations/v1/{co_identifier}
Get collaboration details
✅
PUT /api/collaborations/v1/{co_identifier}/members
✅ but needs a check for the invitation {external_identifier}-> CO -> Unit membership relation
GET /api/invitations/v1/{external_identifier}
Get invitation details
✅ but needs a check for the invitation {external_identifier}-> CO -> Unit membership relation
GET /api/organisations/v1
Get organisation including all collaborations
❌ as the endpoint is currently described, unit managers should not be able to do this. Specifically, the unit manager should not be able to get all collaborations, only those which fall under their unit(s)
proposed solution to this last endpoint is just to scope the token to the user's units and return data associated with those units only.
Notes
Orgs are permanent-ish. Units may come and go. How do we want to tie the lifecycle of the Unit Token to a given Unit? Probably: when Unit ends, token is deleted. Regardless, we must document and make this behavior clear to the user.
Use Cases:
POST /api/collaborations/v1
DELETE /api/collaborations/v1/{co_identifier}
GET /api/collaborations/v1/{co_identifier}
PUT /api/collaborations/v1/{co_identifier}/members
DELETE /api/collaborations/v1/{co_identifier}/members/{user_uid}
PUT /api/collaborations_services/v1/connect_collaboration_service
PUT /api/collaborations_services/v1/disconnect_collaboration_service
POST /api/groups/v1
DELETE /api/groups/v1/{group_identifier}
POST /api/groups/v1/{group_identifier}
PUT /api/groups/v1/{group_identifier}
DELETE /api/groups/v1/{group_identifier}/members/{user_uid}
PUT /api/invitations/v1/collaboration_invites
GET /api/invitations/v1/invitations/{co_identifier}
DELETE /api/invitations/v1/{external_identifier}
{external_identifier}
-> CO -> Unit membership relationGET /api/invitations/v1/{external_identifier}
{external_identifier}
-> CO -> Unit membership relationGET /api/organisations/v1
proposed solution to this last endpoint is just to scope the token to the user's units and return data associated with those units only.
Notes