31–39 of 39 posts
Permit.io Scales both on the tech, and on the human side - e.g. your product manager can add roles (with CI approval) without requiring engineering involvement. (I'm biased but still true)
Permit.io Scales both on the tech, and on the human side - e.g. your product manager can add roles (with CI approval) without requiring engineering involvement. (I'm biased but still true)
I only did a quick read of permit.io offering but iirc they don't focus on hierarchical data. If having access to a resource cannot grant access to unbounded number of other independent resources (eg sharing a folder) then almost all issues of the article disappear
Strange the article proposes itself for "Enterprise" yet has no mention of Google's Zanzibar and how it compares to the other approaches. AFAIK it doesn't use pre-computed values but just queries really fast (using Spanner so there's that)
Google's Zanzibar actually does both : for the vast majority of queries, it uses significant levels of caching and a permitted amount of staleness [1], allowing Spanner to return a (somewhat stale) copy of the relationship data from local nodes, rather than having to wait or coordinate with the other nodes. However, some deeply recursive or wide relations can still be slow, so Zanzibar also has a pre-computation cach…
Isn’t Open Policy Agent (OPA) and Zanzibar not good enough to be in the article or author talking about specific permission controls?
And that it is an internal google system?
Trees with RDBMSes do stay a pain, though :-)
Strange the article proposes itself for "Enterprise" yet has no mention of Google's Zanzibar and how it compares to the other approaches. AFAIK it doesn't use pre-computed values but just queries really fast (using Spanner so there's that)
If you are interested in Zanzibar and Relationship-Based Access Control (ReBAC) it’s worth taking a look at OpenFGA https://openfga.dev/
Earlier quoted context omitted.
Google's Zanzibar actually does both : for the vast majority of queries, it uses significant levels of caching and a permitted amount of staleness [1], allowing Spanner to return a (somewhat stale) copy of the relationship data from local nodes, rather than having to wait or coordinate with the other nodes. However, some deeply recursive or wide relations can still be slow, so Zanzibar also has a pre-computation cach…
Ooh, and back when that was not a thing (iirc a few years back) me and a friend of mine had built a spiritually similar index for spicedb for our final year project at uni. We had a mini WAL and the ability to safely reject queries that specified a minimum update requirement after the index updation.
Earlier quoted context omitted.
Agreed, specifically for the file structure use-case, we were able to solve this with ltree.
About to embark on a similar project. Would love to hear any insights you can share!
1. You have a column on your objects you want secured as an LTREE[] 2. You add a GIST index on that column
The values should be the different hierarchy paths to access the object starting with a "type" e.g departments.root.deptA
When you run a query, depending on how you want to access you use a <@ query. E.g. I'm a user with root access to all depts "col <@ 'departments.root'::ltree" or I'm a user in dept A "col <@ 'departments.root.deptA'::ltree" etc
If you're using Postgres then using the ltree module is great for permission systems. Available in RDS too
Do you have an article about that?
The values should be the different hierarchy paths to access the object starting with a "type" e.g departments.root.deptA
When you run a query, depending on how you want to access you use a <@ query. E.g. I'm a user with root access to all depts "col <@ 'departments.root'::ltree" or I'm a user in dept A "col <@ 'departments.root.deptA'::ltree" etc