Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Abstracting permissions frameworks #1

Draft
wants to merge 31 commits into
base: bug/coral_dockerfile_for_arches_7.5
Choose a base branch
from

Conversation

philtweir
Copy link

@philtweir philtweir commented Sep 23, 2023

Screencast.from.2023-09-23.22-57-41.webm

This is an example for discussion, so is not yet polished

Following up on ideas and challenges that have come up for us, where the established permissions approach is not optimal for our use-cases, this issue aims to open dialogue on how permissions rules could be more internally abstracted.

What is being suggested?

Centralizing (and abstracting) any django-guardian calls such that alternative RBAC logic can be swapped in, in a similar way to how storage backends, search components, datatypes, etc. can be currently.

Why is this necessary?

At present, users or groups are red-listed rather than green-listed by default, which works well when most data is open, but for instances with substantial amounts of non-public data, it can slow indexing for large numbers of users and falls back to allow if any coding/role-assignment issues occur. Moreover, in these cases, some of the (cascading sequences of) checks make group logic less intuitive, and require hooking extra logic on save to get, for instance, per-group visibility of resources.


Screencast shows adding a resource that is visible in search both to the logged-in admin who creates it, and to a public user (Private Browsing). The permissions framework is switched to default-deny in settings.py and the server restarted. The Private Browsing window no longer shows any results. (Note, however, that the count does not reflect the filtering - this may be a general issue)

@philtweir philtweir changed the title Feature/django casbin Abstracting permissions frameworks Sep 23, 2023
@philtweir philtweir marked this pull request as draft September 23, 2023 23:14
@philtweir
Copy link
Author

philtweir commented Jan 23, 2024

The more I think about this, I do feel like the only way to avoid maintaining a fork is to pull this PR apart gradually, and see what is/isn't acceptable into Arches core, with the rest moving to project repo in some suitable fashion.

The core concept here is unchanged, but it now contains extensions to make Casbin useful -- for example, principaluser for a resource, to avoid having to maintain an extremely inefficient extra rule for every resource in the Casbin table, etc. -- I think we need to find a way of paring those out.

@philtweir philtweir changed the base branch from bug/coral_dockerfile_for_arches_7.4 to master January 23, 2024 22:09
@philtweir philtweir changed the base branch from master to bug/coral_dockerfile_for_arches_7.4 January 23, 2024 22:11
@philtweir philtweir changed the base branch from bug/coral_dockerfile_for_arches_7.4 to bug/coral_dockerfile_for_arches_7.5 January 23, 2024 22:13
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant