Add user permissions and authorization use cases to the backend

[kate-holdener]

Is your feature request related to a problem? Please describe.
Our system currently lacks authorization levels. Essentially, any user is allowed to do anything, which is not what we want. We need to manage authorization levels for different users. There are three user roles:

• system administrator
• shelter administrator
• volunteer

The same user can have multiple roles. For example, a shelter administrator can also be a volunteer. A system administrator can also be a shelter administrator. Different shelters can have different administrators, so a shelter administrator role is tied to a particular shelter (or multiple shelters).

A system administrator can:

• create a shelter
• view a shelter
• modify a shelter
• delete a shelter
• be a shelter administrator for any shelter

A shelter administrator can:

• create another shelter administrator
• modify a shelter
  • create a service shift
  • delete a service shift
  • update a service shift
  • create a shelter schedule (schedules will be used to pre-populate service shifts when a shelter admin opens a shelter)
• view a shelter
• be a volunteer

A volunteer can:

• create a service commitment
• delete a service commitment associated with this user
• view service shifts

Proposed design

• roles: SYSTEM_ADMIN, SHELTER_ADMIN, VOLUNTEER
• resource names: SHELTER, SERVICE_SHIFT, SERVICE_COMMITMENT, SCHEDULE, USER_PERMISSION (resource names match our collection names)
• actions: CREATE, READ, UPDATE, DELETE
• Permission structure contains:
  • resource name
  • actions
  • resource ids
• Role structure contains
  • unique id
  • role
  • list of permission objects
• UserPermission structure contains:
  • unique id
  • user email
  • list of role ids

To handle authorization, we need to define a few use cases.

1. get_user_permissions(email: str) -> Set[Permission]
2. user_has_permission(email: str, resource: Resource, action: Action, resource_id: str)
3. add_permission(email: str, resource: Resource, actions: List, resource_id)

Once these use cases are in place, we can update our api endpoints to check permissions before processing a request.

Additional context
Authentication will be handled separately. User will need to be authenticated before we process authorization.