Design permissions & multi-user system #2

Open
opened 2021-12-21 09:49:19 +01:00 by Jef Roosens · 0 comments

I have several ideas that would ideally need a way for configuring granular permissions with multiple users on the platform. That's why I want to design a permissions system.

Current idea

The authentification microservice will keep track of all users. Each user is linked using an inner join to a table containing one or more rows linking a user to a permission ID. These ideas could either be an integer, or a string (might be more structured). These permissions could then be passed to the frontend using JWTs. When a user then sends an API request, each endpoint checks wether the user has the correct ID in their list of permissions, blocking the request if needed.

Alongside this, an api (also containing its own proper permissions) for editing these permissions should be put in place.

Permissions will be divided into categories (e.g. sections, pastebin, url shortener, etc.) with each category containing granular sub-permissions, with an overarching "allow all permissions" ID for that specific category.

For example, say we have the "sections" category. These category could then contain "creating sections", "removing sections", "editing metadata", just to name a few.

A possible idea for an ID could be a 64-bit unsigned integer, where the first 32 bits define the section & the last 32 the permission within that category. A fixed length ID would probably be a good idea, as this would allow us to efficiently use bit operations for matching permissions.

Roadblocks

The most difficult part I think will be syncing these permissions along the various microservices. It'll be important to define a good ID structure as early as possible, & making sure no ID for a given category/permission ever changes throughout development.

I have several ideas that would ideally need a way for configuring granular permissions with multiple users on the platform. That's why I want to design a permissions system. ## Current idea The authentification microservice will keep track of all users. Each user is linked using an inner join to a table containing one or more rows linking a user to a permission ID. These ideas could either be an integer, or a string (might be more structured). These permissions could then be passed to the frontend using JWTs. When a user then sends an API request, each endpoint checks wether the user has the correct ID in their list of permissions, blocking the request if needed. Alongside this, an api (also containing its own proper permissions) for editing these permissions should be put in place. Permissions will be divided into categories (e.g. sections, pastebin, url shortener, etc.) with each category containing granular sub-permissions, with an overarching "allow all permissions" ID for that specific category. For example, say we have the "sections" category. These category could then contain "creating sections", "removing sections", "editing metadata", just to name a few. A possible idea for an ID could be a 64-bit unsigned integer, where the first 32 bits define the section & the last 32 the permission within that category. A fixed length ID would probably be a good idea, as this would allow us to efficiently use bit operations for matching permissions. ## Roadblocks The most difficult part I think will be syncing these permissions along the various microservices. It'll be important to define a good ID structure as early as possible, & making sure no ID for a given category/permission ever changes throughout development.
Jef Roosens added the
idea
label 2021-12-21 09:50:23 +01:00
Jef Roosens added this to the 0.2.0 milestone 2021-12-21 09:50:26 +01:00
Sign in to join this conversation.
No Milestone
No project
No Assignees
1 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: rusty-bever/auth#2
There is no content yet.