Skip to content

Proposal: Adding Operation-Based Permissions to CTMS #1016

@robhudson

Description

@robhudson

Background

Currently, the CTMS API uses client authentication credentials that provide blanket access to all operations. Any authenticated user can perform any action, leading to potential security and data integrity risks. To address this, I propose implementing operation-based permissions to assign specific access rights to specific named roles which are then assigned to the api_client records. Operations are loosely mapped to the CTMS API, e.g. add_contact.

Objective

Introduce operation-based permissions to CTMS to

  • Restrict access to operations based on roles.
  • Ensure control over API operations (e.g., create, read, update, delete) at the operation level.
  • Enhance the security of sensitive user data, particularly the "emails" table, by limiting delete access to a small set of roles.

Proposed Solution

Core Components

  1. Access Groups
    • Define specific named roles.
    • Associate API credentials with one or more roles.
    • Include an overall Admin role similar to Django's superuser.
  2. Operation-Based Permissions
    • Implement permissions for specific operations.
    • Example permissions:
      • create_contact
      • read_contacts
      • update_concact
      • delete_contact (restricted to a small subset of roles).
  3. Role-Based Access Control
    • Map roles to permissions.
  4. User-Based Access Control
    • Consider whether we also need user-based access control

Implementation Steps

  1. Database Schema Updates

    • Add tables/models to track roles, permissions, and operation-level associations:
      • roles: Store role definitions (e.g., AMO Admins, Newsletter Managers).
      • permissions: Define actions for each type (e.g., create, read, etc.).
      • role_permissions: Map roles to permissions.
      • client_permissions: If a client doesn't fit into a specified role, they could have their own specific permissions assigned.
  2. Permission Checking Tooling

    • Write tooling to help manage and view permissions and roles.
    • Develop permissions checks mechanism (via fastapi dependency injection?)
  3. API Updates

    • Update existing endpoints to:
      • Enforce permission checks.
      • Respond with appropriate error messages (e.g., 403 Forbidden) for unauthorized actions.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions