tldr
Readit Newsalex-olivier commented on Have attention spans been declining? slimemoldtimemold.com/202... · Posted by u/janandonly
alex-olivier commented on AWS Creates New Policy-Based Access Control Language Cedar infoq.com/news/2023/02/aw... · Posted by u/msolujic
For me personally, it would be much more useful if I could play with the policies interactively - issue requests with some tagging (a special access key maybe?) and see what permissions they need, what context they have and which of them are allowed/denied by the policies. And what if I edit this part, would it affect the recorded requests?
At the moment, it usually takes me several iterations to tune the policy.
(Disclaimer: I work for Cerbos[1])
When we started working on Cerbos[1] the very first external bit of tooling we released was the Cerbos Playground[2] which does exactly what you say - allows you to see the requests and responses as they make changes to their policies, making it easier to test and refine their rules.
This is a great starting point to prototype and test whether a decoupled authorization system is right for your use case. Cerbos uses YAML rather than a custom DSL to try and address the fact that authorization requirements generally don't sit with developers, rather a product owner of some sorts who is going to want to be able to comprehend the logic behind the permissions model.
When it comes to Authentication and Authorization, these are both core components of a system but undifferentiated building blocks so wouldn’t recommend building them yourself.
Typically using something like Auth0, Cognito, Firebase Auth, FusionAuth, Clerk or many of the other authentication services will get you a full feature set for user management with little to no work.
On the authorization front consider a similar approach of decoupling the the component out of your codebase where the permissions logic is defined as policy rather than code. I work on Cerbos[1] which is an open-source, decoupled authorization layer for your software which does exactly this.
Not the only permissions issue at GitHub
Disclaimer: I work for Cerbos[0].
Whilst this is a very good approach when all your data is stored in a single datastore, as applications grow it is common to start breaking out into more optimised data stores eg you may have few relational databases, a fast lookup source and a search index. This presents a problem of enforcing authorization down into each system.
An alternate way to tackle this is to have the authorization system produce the conditions which need to be applied dynamically at request time (with all the relevant context) which can then be pushed down to each fetching layer as needed [2][3]. This gives far more flexibility in the sorts of authorization rules which can be applied to the data and doesn't tie it to a single bit of technology.
As a real world example we have an integration with Prisma[3] which maps a query plan into a Prisma query format dynamically based on the context of the user and the currently live policies[4].
[0]: https://cerbos.dev
[1]: https://cerbos.dev/blog/filtering-data-using-authorization-l...
[2]: https://docs.cerbos.dev/cerbos/latest/api/index.html#resourc...
[3]: https://prisma.io/
alex-olivier commented on The Case Against Token-Based Authorization cerbos.dev/blog/my-post-t... · Posted by u/alex-olivier
Is that extra database call to get auth status really that costly? Having the client hold any kind of access control is scary to me.
(I lead product at Cerbos[1])
Certainly agree and we have seen a lot of cases of JWT tokens getting bloated with more and more authorization data.
Using JWTs to hold the autheNtication information is a standard now but consuming that and applying fine-grained access controls for authoriZation using that context with a system that can enforce policies is that next step.
Having a dedicated AuthZ system in place that sits after the AuthN layer should put your mind at rest as a good one will provide a central point for all authZ logic which can be managed, tested and audited for every action within a system.
One area that is a constrained and narrow use case is around the actual application level permissions - eg what a user can do inside of your service. Having hand-rolled this in various companies - and the inevitable rebuilds that were required as requirements change such as adding a new, product packaging updates etc - you do end up with a complex web of logic - ether in your codebase or as Rego.
For these application level permissions - where the requirements really come from the product/business rather than engineering - I always felt there could be a simpler way of defining this rules. Policies needed to be in a format a business user could understand, and enforcing them needs to be extremely responsive as checks are in the blocking path of every request - and this needs to work at large scale - all whilst making every decision auditable to tick all the regulatory and compliance needs around access controls.
To this effect we begun working on Cerbos[0] a few years ago which initially targets that one specific use case - models policy in simple YAML [1] (love it or hate it!) and takes a stateless approach meaning it is infinitely scalable with none of the headache of synchronizing information about your users or resources to the authZ layer, also critically generates that single audit log of decisions.
Disclaimer: I work on the team that builds and maintains Cerbos[2].
[0] https://github.com/cerbos/cerbos
[1] https://play.cerbos.dev/p/XhkOi82fFKk3YW60e2c806Yvm0trKEje
[2] https://cerbos.dev