Aserto looks very promising (https://www.aserto.com/), but it still in private beta.
It's crazy this still is part of the stack where there are no great solutions.
Aserto looks very promising (https://www.aserto.com/), but it still in private beta.
It's crazy this still is part of the stack where there are no great solutions.
Seems like a few others have come to the same conclusion :)
We're working on this at Oso (https://osohq.com) - I'm the CTO. Oso is an open source framework for authorization. Policies can reference application directly, so any authorization decisions can be made dynamically based on the data. And your data doesn't need to leave your application.
> Often the issue is the inability to easily push down filters into the database or search index.
We actually support pushing down filters into the database directly through a feature we call... data filtering. We support Django and SQLAlchemy today (https://docs.osohq.com/python/guides/data_access.html) but will be making this available for non-ORM/non-Python users in the next few months.
It's indeed a hard problem, because you want the solution to have the operational characteristics of a library (millisecond latency / 100% available to the calling application), but at the same time, give you the convenience of a service / control-plane (allow you to centrally manage the lifecycle of authorization policies, sync properties about the users to the edge, drain all the decision logs back to the control plane, etc).
It's one of the most frustrating wheels that developers still have to re-invent, and it's great to see more companies trying to innovate in this space.
As @tristanz mentioned we're in private beta, and happy to engage with folks that want to solve AuthZ :)
It's also based on Zanzibar, and it's used in production applications today. Cloud version coming soon (using cockroachdb) or use the open source version (postgres).
agreed that it's wild that this isn't solved for b2b apps in 2021. the 80's were when most fundamental innovation happened here, then fundamentally more flexibility in the xacml days (~arbac), yet here we are...