Skip to content

Commit

Permalink
Merge pull request #477 from permitio/orweis-patch-2
Browse files Browse the repository at this point in the history
expand on data filtering options
  • Loading branch information
orweis authored Jan 6, 2025
2 parents c860ea7 + d84956e commit 3a29a49
Showing 1 changed file with 17 additions and 11 deletions.
28 changes: 17 additions & 11 deletions docs/how-to/enforce-permissions/data-filtering.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -7,7 +7,23 @@ Implementing data filtering within access control represents a different approac
Instead of merely granting or denying access, it curates what users see, tailoring the data to their individual permissions.
This method ensures not only secure access but also optimized data delivery.

## Simple usage
When working to filter data (e.g. data coming from databases), there are two main types of authorization:

1. **Boolean Query Filtering**: This involves checking whether a query should be allowed to execute. Here, the query is translated from SQL to a policy (e.g., using an Abstract Syntax Tree (AST) for SQL, or such as this [simple parser for Couchbase N1QL](https://www.couchbase.com/blog/permit-io-couchbase-access-control/)). Essentially, the query is mapped to resources and actions, and these are enforced with a standard check.

2. **Data Filtering from Queries**: This has four subtypes:

- **Application-Level Filtering**: In this method, the whole data is fetched from the DB and then uses a set of boolean results obtained from the Policy Decision Point (PDP) through [bulk checks](/how-to/enforce-permissions/bulk-check).
- **PDP-Level Filtering**: In this method, the data is fetched from the DB, and then use the `filterObjects` function [(see below)](#pdp-level-filtering), which returns a subset of the objects passed to it based on the policy.
- **PDP-Level Filtering Based on the Information Graph**: This method involves returning pre-filtered objects based on data synchronized with the PDP in advance. It includes functions like [`getUserPermissions`](/how-to/enforce-permissions/user-permissions) (which returns all objects a user has access to) and [`getAuthorizedUsers`](/how-to/enforce-permissions/authorized-users) (which returns all users who have access to a specific resource). In this method, the allowed objects returned from the authorization graph are added to the DB query before making the query.
- **Source-Level Filtering (in the Database)**: Also known as Partial Evaluation, where 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 [Open Policy Agent (OPA) under the `compile` API](https://www.openpolicyagent.org/docs/latest/rest-api/#compile-api) and is already available within Permit’s PDP. In this method the DB query is modified before being executed against the DB.
- [Simplified Partial-evaluation](https://youtu.be/wgNhtbqW-hs?t=238), is an upcoming feature in advanced stages of release, which includes built-in translation to SQL.




## PDP-Level Filtering
Below is a simple use example to use `permit.filterObjects`

```go
package main
Expand Down Expand Up @@ -53,14 +69,4 @@ func main() {

```

## Advanced Usage

:::tip STAY TUNED!
In the near future, you'll be able to seamlessly integrate permission enforcement directly into your database queries
using **partial evaluation**.

This advanced integration will analyze your policies,
formulate optimized query filter conditions,
and facilitate the incorporation of these conditions into your database queries.
This ensures that the data retrieved is strictly confined to what the user is authorized to view.
:::

0 comments on commit 3a29a49

Please sign in to comment.