There's an interesting section here about one of my favourite challenges in authorization: how to efficiently return a list of things that the current user has permission to access, without running a "can_access()" permission check on every single one of them (which is bad if you have thousands of items and you want to paginate them).

Their solution is to let you configure rules that get turned into SQL fragments that you can run against your own database: https://www.osohq.com/docs/guides/integrate/filter-lists#lis... - example Rails app here: https://github.com/osohq/rails_list_filtering_sample_app

A team I worked with in the past came to the same conclusion - turning authorization rules into WHERE clauses is a very efficient way to solve this problem, if you can figure out a clean way to do it.

I tend to build the "ownership" model whenever I can. It works extremely well and has a few simple rules:

1. a user can own an entity/row/unit/whatever. They have full control over this unit.

2. a user can share ownership with another user/role.

3. a user can share various "rights" over any units they own -- CRUD, for example -- for any user/role.

4. a user can only interact with any unit they have a right to.

This can be implemented through a simple db table (or inline in the data itself) and doesn't depend on much. Once you build the middleware, you don't even need to think about the authorization layer.

Congrats on the launch!

[Disclosure: I'm one of the co-founders of Aserto, the creators of Topaz].

The problem of data filtering is indeed a huge part of building an effective authorization system. Partial evaluation is one way of doing it, although with systems like OPA [0] it requires a lot of heavy lifting (parsing the returned AST and converting it into a WHERE clause). Looking forward to seeing how turnkey that can be with Oso.

With that said, there are applications where you really want the data close to the authorization engine. With a ReBAC model, you can easily find the objects that a user has access to, or the users that have access to an object, by walking the relationship graph. That's the approach we've taken with Topaz [1].

Funny timing - a few days ago we published a blog post on that very topic! [2]

[0] https://openpolicyagent.org

[1] https://topaz.sh

[2] https://www.aserto.com/blog/how-rebac-helps-solve-data-filte...

Hey all!

I'm Sam, cofounder + CTO at Oso.

Thank you all for the great discussions going on here. If folks are interested in either learning more about the product or working on these kinds of problems, you can email me directly at sam [at] osohq.com.

Kinda sounds like OPA (Open Policy Agent) [1], but a different implementation.

[1] https://www.openpolicyagent.org/docs/latest/

> Suppose you decide to add teams to gitcloud, so different teams in an organization can have different permissions. Will you be able to find all the functions and queries you need to modify in order to make teams work properly? Do you want to have to do that? > This is why we introduced Polar, our declarative DSL for authorization. Polar allows you to separate your authorization logic from your application logic and express it in a language that is purpose built for authorization. A simple Polar policy looks something like this:

First, I appreciate that it is the Polar "programming language" and not yet another kind of stupid YAML DSL.

However: you seem to target developers. Why do you force me to leave my IDE and use your "rules editor"? Can I not write all those things in my IDE, with all the support it brings, and integrate this into my CICD flow? (yes, there is the .polar file, but why force me to jump through hoops?)

Then, why did you create a new DSL and not a merely a (de-)serializable datastructure (which will indeed look like a dsl)? One, that is powerful enough to represent the capabilities you need. Then, I could in fact use any language (library) of my choice and create the rules from this language, which just has to create the datastructure.

Or, backwards: why do you think authorization is so special that it deserves a custom language? Is it more special than performance-testing, logging, auditing, debugging, metrics and so on?

Apart from that, I really like the `yes, if` idea! Would be nice to hear a bit more about that (unfortunately, the article pretty much ends there). Such as: how to deal with actions that change things and can (or must) potentially be run before the authorization is completed and such.

Slightly tangential, but is there any hope of seeing Polar return as a (maintained) open source system?

I absolutely love the concept of using a logic language for authorization, and I think Polar's aesthetic qualities make it significantly more approachable for most people (over Prolog/Datalog).

But even without the authorization problem, Polar is just... really nice looking. It would be awesome to be able to use it as its own language outright.

Quick note for the osohq team: The "Read the docs" button leads to 404

Is it self hosted? I can't see any docker image

This is a product launch. Full title: "Authorization is still a nightmare for engineers: Launching Distributed Authorization"