mitgliederverwaltung/docs/roles-permissions.md

Role and Permission Concept

Goals

High-level concept

• Constraints
  • Roles are predefined, but can be renamed, removed, added
  • Permissions for each role can be configured
• Use Cases
  • restrict read or write access to specific member data, groups and pages for certain roles
    • this includes built-in hardcoded fields such as address, payment information, payment history, etc.
• Example Roles
  • Vorstand
    • Access to members, but not to users
  • Kassenwart
  • Buchhaltung
  • Admin
• Role should decide which custom fields, members and pages to show
  • e.g. changing custom field definitions should only be done by admins

Permission

• Subject: user with exactly one role
• Action: read, write (create, update, delete)
• Object:
  • users, custom fields, groups, roles, user credentials
  • page, group, members in a group, member field, custom field value, Payments

Rules

Every user can be assigned one out of the four basic permissions:

1. Basic (default) - Every user can always read and write their own credentials, member fields, custom field values, and group associations
2. Read-only - Permissions for reading, no writing rights
   • all members
   • all group association
   • specific pages
   • all custom fields values (indirectly the custom fields' definitions)
   • all hardcoded member fields except credentials
   • payment history: yes/no
3. Normal User - permissions for writing (implies permission to read)
   • specific pages,
   • always all members: yes/no,
   • all custom field values (and reading their custom field definitions),
   • all member fields except credentials,
   • payment history: yes/no
4. Admin - Permission for reading and writing: users, custom fields, groups, roles, user credentials

Each of these permissions can be split up in the future to provide more granular access controls, e.g. for only accessing specific fields of a member. For each operation, authorization checks in the code should already take the subject, action and object as arguments to make it easier to migrate to fine-grained permissions in the future.

Some special object notes:

• user credentials (email & password)
  • users can always write their own credentials
  • only admins can write credentials for other users
  • Enforce these rules also when editing the email of an associated member
• Pages
  • Opening a page is always considered a read action, even if the page contains forms for updating other authorization objects
  • For each page, define which roles can access it
• Member fields
  • special handling of email field, if it's associated to a user

Other

• UI/UX: Independently of permissions, users might want to hide some pages, member fields or groups because they don't need them. These should be individual settings. We should create a ticket for mocking this up.