hi permitters! i am exploring using your product for implementing rebac data filtering in my python/django project - i have some questions about the implementation. apologies for any misunderstandings - i have just started looking. details in a thread 🧵

Hi @Liam Taylor, I'm an AI assistant for Permit.io. I'll analyze available sources and get back to you shortly.

my understanding of how i might got about this is as follows. this is based on using the PDP/Python SDK • in a view, extract the data to be filtered from the database • serialize it (or a subset of the data) • call

Permit.filter_objects

with this data and the rest of the required stuff, which return the filtered data set • (if the data sent to permit is a subset of the data the full data set based on the

filter_objects

response under the hood, my understanding is that permit • makes an external API call to get relevant permissions • filters the data in python code based on those permissions currently our filtering is applied as the database layer. i'm worried that moving this to permit wouldn't be scalable based on latency of building in an external API request, the amount of data needing to be transferred (if all filtering logic is covered by permit, then that is effectively always an entire database table), and the efficiency of filtering large data sets in python. can you advise to this end? i am very aware that i am possibly misinterpreting certain things. ideally i would be able to use permit's permissions to create appropriate SQL queries that reflect the permissions. this is in line with the source-level filtering references in this section of the docs - is there any guidance on implementing this? is this out of the box functionality?

Hey! Great to hear you're exploring Permit.io for ReBAC data filtering in your Django project. I'd be happy to help answer your questions! Permit.io supports ReBAC (Relationship-Based Access Control) in Django applications, which allows you to create fine-grained permissions based on relationships between users and resources (1) . This is particularly useful for implementing data filtering where users should only see data they have relationships with. For Django specifically, you can implement ReBAC by: 1. ​*Defining relationships in Permit.io*​ - Set up your resources, roles, and the relationships between them in the Permit.io dashboard 2. ​*Using decorators for permission checks*​ - Apply the

@check_permit_permission

decorator to your Django views (2) :

@check_permit_permission(action="read")
def list(self, request) :
    queryset = self.get_queryset()
    serializer = self.serializer_class(queryset, many=True)
    return Response(serializer.data)

3. ​*Implementing the permission check middleware*​ (1) :

from permit.sync import Permit
from dotenv import load_dotenv
from django.http import JsonResponse
from django.views import View
load_dotenv()
permit = Permit(
    pdp= os.getenv("permit_pdp_url") ,
    token= os.getenv("permit_sdk_key")
)
class PatientDetailView(View) :
    def get(self, request, patient_id) :
        permitted = permit.check(request.user.email, "view", "patient_record")
        if not permitted:
            return JsonResponse({"error": "Access denied"}, status=403)
        
        # Retrieve and serialize patient data
        patient = Patient.objects.get(id=patient_id)
        serialized_patient = PatientSerializer(patient) .data
        
        return JsonResponse(serialized_patient, status=200)

(3) Feel free to share your specific questions in the thread - I'm here to help with the implementation details!

Hey @Liam Taylor , welcome (: We will right back to you, Meanwhile, does the AI answered your question?

Hi Alon - nice to meet you! Not really - I'm more interested in understanding how Permit works under the hood and how this might impact the performance

Hi Liam there are multiple options you can consider for data filtering with Pros and Cons. • Via Partial evaluation (Rego ast to SQL), which we don't recommend anymore • Via bulk check calls • Via getUserPermissions / getAuthorizedUsers And maybe most interestingly we have a POC using Trino to do the filter in front of the DB which I believe @Gabriel L. Manor can share with you

Sure! You can see the way it works with the CLI here: https://github.com/permitio/permit-cli?tab=readme-ov-file#env-apply-trino @Dan might give more details on the BE implmentation

@Ask Inkeep and @Gabriel L. Manor My team is looking to solve filtering as well and came across this thread. We’re currently using bulk checking, but want to filter at the DB instead of application layer post query. • What are the reasons partial eval is no longer recommended? • Is there an example of how to filter with Trino? I saw the link to the CLI, but it wasn’t clear to me how that solves the filtering problem.

Thanks for tagging me @Sam Jakos. I'll look through relevant sources and get back to you shortly.

Hey, thanks for reaching out ! It seems our team is a little busy right now, a human will be with you within the next hour or so. In the meantime, can I help you ?

Great questions about data filtering! Let me address both of your concerns: Partial Evaluation Status While partial evaluation (converting policy rules to SQL queries) is mentioned in the documentation, there's an indication it may have evolved. The documentation mentions that partial evaluation exists in OPA under the

compile

API and is available within Permit's PDP (1) . It also notes that "Simplified Partial-evaluation" is described as "an upcoming feature in advanced stages of release, which includes built-in translation to SQL" . For the most current approach, Permit offers "early access support for Postgres partial evaluation, enabling policy rules to be directly converted into SQL queries without requiring manual Rego or policy compilation" (2) . Trino Integration for Database Filtering The Trino integration works by introspecting your database schema and creating a comprehensive policy model in Permit (3) . Here's how it helps with filtering: How Trino Setup Works:

permit env apply trino --url <http://localhost:8080> --user admin --api-key permit_key --catalog postgresql --schema public

This command maps your database structure to Permit resources : • Tables →

trino-table-<catalog>-<schema>-<table>

• Columns →

trino-column-<catalog>-<schema>-<table>-<column>

• Views →

trino-view-<catalog>-<schema>-<view>

Available Filtering Approaches For database-level filtering instead of application-layer, you have these options (1) : 1. ​*PDP-Level Filtering Based on the Information Graph*​ - Returns pre-filtered objects based on data synchronized with the PDP in advance using functions like

getUserPermissions

and

getAuthorizedUsers

. The allowed objects returned from the authorization graph are added to the DB query before making the query . 2. *Source-Level Filtering (Partial Evaluation) * - The PDP returns a query basis (e.g., SQL) that is sent or appended to an existing query and sent to the database, which returns the relevant data pre-filtered . This capability exists in OPA under the

compile

API and is already available within Permit's PDP . Example of Information Graph Approach: Instead of bulk checking after fetching data, you can query permitted resources first (2) :

// Ask the PDP which 'documents' Alice can read (across tenants, or just one)
const userPermissions = await permit.getUserPermissions("<mailto:alice@example.com|alice@example.com>", [], [], ["document"]) ;

// Extract the allowed document IDs
const allowedDocIDs = userPermissions
  .filter(entry => entry.resourceType === "document")
  .map(entry => entry.resourceKey) ;

// Fetch only permitted documents from the DB
const permittedDocs = await db.Document.find({ id: { $in: allowedDocIDs } }) ;

This approach identifies the subset of authorized documents in advance, avoiding fetching irrelevant rows in the first place . The Trino integration essentially creates the policy structure needed to support these filtering approaches by mapping your database schema to Permit's authorization model.

Re: partial eval - We saw that as the requirements grow in complexity the complexity of the AST grows exponentially and so doe sits variance, and we judged as non sustainable - and so don’t recommend it Re: Trino - @Gabriel L. Manor is on PTO - will be back tomorrow and he (or @Dan ) should be able to answer

Thanks for the answer, looking forward to hearing from the others on the Trino approach. Without Trino, what would the recommended implementation?

The AI gave a good answe here on the other data filtering options. See docs here as well https://docs.permit.io/how-to/enforce-permissions/data-filtering/

@Gabriel L. Manor welcome back! Looking forward to your input.

Hey! You can integrate Trino with Permit using our CLI and the command

env apply trino

that implements the Trino schema as a Permit policy schema. Then, you can connect it to CI/CD or other automated workflows that listen to the schema changes. Read the docs here: https://github.com/permitio/permit-cli?tab=readme-ov-file#env-apply-trino We also have some built-in pdp functions to help with filtering, @Dan can shed some more light on it.