django_scoped_rbac
A rich and flexible Django application for role-based access control within distinct access control scopes supporting Django Rest Framework.
Motivation
Support multiple security contexts within an application, rather than having the application serve as the single security context.
Support a model of security context that can be enforced at the query level within the database. For example - list all resources within the contexts the user is authorized to list resources.
Support assignment of roles within a security context.
Support an extensible mechanism for conditional policy expressions for permissions.
Support a JSON representation of the total permissions granted to a user for all security contexts that can be shared with browser and other clients to enable permissions-informed disclosure UI and UX
Support multiple security contexts within an application
Most RBAC systems provide a simple permission model to answer permissions. For example, is the user authorized to POST a comment. In an application that supports multiple security contexts the relevant context is an additional parameter required to determine if the user is authorised; that is is the user authorized to POST a comment to this project vs another project. A user may be authorized to POST a comment to one project, but not another.
Support for security contexts at the query level
If every object has a security context property it’s possible to always secure the queries executed for a user request by adding the user’s authorized security contexts as an “IN” condition restricting the scope of the query.
Support assignment of roles within a security context
In most RBAC systems a user is assigned a role that is applicable across the entire application. For example, a user may have a Commenter role granting the user the permission to post comments anywhere comments may be posted within the application. An application that supports the assignment of a role within the scope of a specific security context can restrict the assignment of the Commenter role to specific areas of an application. For example, a user may be assigned the Commenter role in Project 1 but not Project 2.
Support an extensible mechanism for conditional policy expressions
Another limitation of most RBAC systems is the simplicity of their permissions - you are either authorized to perform an action or not. Supporting an extensible mechanism for conditional policy expression means that a permission may be conditionally granted dependant upon a variety of factors. For example, you may be granted the permission to comment within a project only when a target resource within the scope of that project is “open for community comments” vs “open for drafter comments”.
Support JSON representation of total permissions granted
If a user has permission to perform an action, such as update a resource, it should be possible for a client to determine that this is the case and be able to decide whether to disclose editing capabilty for the resource to the user. That is, if I’m not authorised to edit a resource the UI shouldn’t offer me the opportunity to edit the resource.
Providing a JSON representation of the user’s total permissions, and a Javascript implementation of the permissions policy engine, can provide a much richer user experience.
Installation
Requires Python 3.11+, Django 5.2+ and Django REST Framework 3.15+.
uv add django-scoped-rbac # or: pip install django-scoped-rbacAdd "scoped_rbac" to INSTALLED_APPS and configure policies with the SCOPED_RBAC setting.
Conditional policy expressions
Policy conditions are written in the Common Expression Language and evaluated with Google’s cel-expr-python runtime. Each top-level key of the resource being authorized is available as a variable, for example content.status == "open". An expression that fails to evaluate denies access.
Custom functions are registered with CEL_FUNCTIONS. Because the CEL runtime dispatches on argument types, each function’s parameters must be annotated with bool, int, float, str, bytes, dict or list; a function that needs several signatures can be given as a cel_expr_python.cel.FunctionDecl instead:
# myapp/workflow.py
def is_allowed_transition(current: str, proposed: str) -> bool:
...
# settings.py
SCOPED_RBAC = {
"CEL_FUNCTIONS": {
"is_allowed_transition": "myapp.workflow.is_allowed_transition",
},
}Development
The project is managed with uv:
uv sync # create .venv with the dev dependencies
uv run pytest # run the tests with coverage
uv run ruff check && uv run ruff format --check
uv run --group docs make -C docs html # build the docs into build/sphinx/html
Release files for django-scoped-rbac 0.10.1
For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.
Source distribution (sdist)
| File | Size | Uploaded | Provenance | |
|---|---|---|---|---|
| django_scoped_rbac-0.10.1.tar.gz | 30.4 kB | Without provenance | Details |
Built distribution (wheel)
| File | Interpreter | ABI | Platform | Reset |
|---|---|---|---|---|
| django_scoped_rbac-0.10.1-py3-none-any.whl | Python 3 | none | any | Details |
Total release size: 67.5 kB
Release files / django_scoped_rbac-0.10.1.tar.gz
| Download URL | django_scoped_rbac-0.10.1.tar.gz |
|---|---|
| Size | 30.4 kB |
| Tags | Source |
|
SHA-256 checksum How to use checksums |
05d9d92df14651a98c14ff5bdfcefcf15b45aebee5f5030e6e9deb3e649b0d79
|
|
BLAKE2b-256 checksum How to use checksums |
b3471420ff6ff1e6da4f25a41298889239386eb0f6baf8cf5aa839b967cd1705
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
No |
| Uploaded via |
uv/0.9.30 {"installer":{"name":"uv","version":"0.9.30","subcommand":["publish"]},"python":null,"implementation":{"name":null,"version":null},"distro":{"name":"Debian GNU/Linux","version":"12","id":"bookworm","libc":null},"system":{"name":null,"release":null},"cpu":null,"openssl_version":null,"setuptools_version":null,"rustc_version":null,"ci":true}
|
Release files / django_scoped_rbac-0.10.1-py3-none-any.whl
| Download URL | django_scoped_rbac-0.10.1-py3-none-any.whl |
|---|---|
| Size | 37.1 kB |
| Tags | Python 3 |
|
SHA-256 checksum How to use checksums |
39fd310d92347bac14bd8fbec0854f5d43747336383654fc5ae7f5e065bc2ab2
|
|
BLAKE2b-256 checksum How to use checksums |
c8547ebcc43c6d3ce4208674a6c95cec999996ca070fbe99f290aa84a8f80964
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
No |
| Uploaded via |
uv/0.9.30 {"installer":{"name":"uv","version":"0.9.30","subcommand":["publish"]},"python":null,"implementation":{"name":null,"version":null},"distro":{"name":"Debian GNU/Linux","version":"12","id":"bookworm","libc":null},"system":{"name":null,"release":null},"cpu":null,"openssl_version":null,"setuptools_version":null,"rustc_version":null,"ci":true}
|
Security for django-scoped-rbac 0.10.1
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
No provenance found
None of the files in this release were uploaded with provenance metadata.
A note on package security
PyPI is a repository for distributing packages, not a service for auditing them. While third-party security researchers and our staff do their best to detect and remove malicious packages, PyPI cannot guarantee the quality, security or suitability of any given package.
To learn more about protecting yourself from malicious actors, visit our package security documentation.
