Implement API Path-Based Permissions for Granular Access Control

[mkrenzke]

Referring to:

I think the long term solution to this is a user settings page where this can be set up, and other settings can be modified by users with sufficient access. I think it's also maybe not a bad idea to set up an api.foo.bar style permission, where users could use paths of the API only with the correct permissions.

Originally posted by @b-rowan in #275

To enhance security and access control, we should consider implementing API path-based permissions. This would allow users to access specific API endpoints only if they have the necessary permissions, adding an extra layer of security beyond authentication.

Proposed Approach:

1. Introduce a new permission system where API paths (or groups of paths) are mapped to required user roles or permissions.
2. Define a permission format like api.foo.bar to control access to different API sections.
3. Enforce these permissions at the API level, ensuring users can only call endpoints they are authorized for.
4. Provide a way for administrators to configure and assign these permissions to users.

This would complement the existing authentication system and help enforce least-privilege access.

Would love to hear thoughts on this approach and any potential implementation considerations!

[b-rowan]

Got a start on this in the linked PR, along with a full rework of user access control. Let me know any initial thoughts, but I likely wont be able to complete this for at least another week, since I am away on a business trip this week.

[tsagadar]

This sounds like a bigger feature. Is it worth all the initial work and future maintenance effort? I think keeping gooseBit simple and lean also has its benefits.

Even the current permission systems seems to flexible to me. I'd be fine with 2-3 predefined roles that make sense in a software update system. This would fit the "oppiniated" claim and prevent of becoming too complex (ie. better start from the use cases than build a toolbox that allows to do everything).

[b-rowan]

This sounds like a bigger feature. Is it worth all the initial work and future maintenance effort? I think keeping gooseBit simple and lean also has its benefits.

Even the current permission systems seems to flexible to me. I'd be fine with 2-3 predefined roles that make sense in a software update system. This would fit the "oppiniated" claim and prevent of becoming too complex (ie. better start from the use cases than build a toolbox that allows to do everything).

I sortof agree with this, but I still think I want to be able to configure users via the GUI at some point anyway, so working on that now with the linked PR.