Service-bound Resources and Permissions
Currently permissions are represented by groups. This applies to both uffd-internal permissions (e.g. admin rights in uffd) and service permissions (e.g. admin rights in rocketchat). For service permissions this is somewhat limited:
- The groups of a user are global, so every service sees all permissions a user has
- Services with complex resources and permissions either require
- local configuration (e.g. encoded in custom sync scripts) that map uffd groups to actual permissions on resources.
- a complex encoding scheme for group names. This is barely possible, since they are length-limited.
I propose a service-bound resource and permission model (example: mailman3):
- Resource types: Admin-configured types of resources with unique names (e.g. "list" for mailinglists)
- Resources: Instances of resource types with a unique value (e.g. for every mailinglist with the list name as the unique value)
- Permission types: Admin-configured types of permissions, either related to a resource type or freestanding (e.g. "member" for the "list" resource type and "admin" as a freestanding permission for the service)
- Permission: Instance of permission types. For resource-type-bound permission types, there is a permission instance for every resource of that type (e.g. a "member" permission object for every mailinglist). For each freestanding permission types there is just one instance.
- Similar to groups, permissions can be added to roles
- Similar to groups, users have the permissions of their effective roles
- getusers API endpoint returns an additional "permissions" field with the names of the freestanding permissions a user has and a "resources" field with a value similar to
{"RESOURCE_TYPE1": {"RESOURCE_VALUE1": {"permissions": [names of permissions]}, ...}, ...}
- New API endpoint to retrieve all resources
- Resources can have extra admin-configured data/setting (free-form JSON), e.g. for a mailinglist whether or not members are auto-unsubscribed if they don't have the "member" permission for that list. This extra data would be available in both the getusers field and the new resources endpoint