Architecturally, the Aserto authorizer is packaged up as a docker container and deployed as a sidecar or microservice in a customer environment. The control plane typically runs in Aserto's cloud (although you could run it on your own if you needed full control of the end-to-end solution).
[1] https://www.openpolicyagent.org/
But fundamentally I meant that it doesn't seem like you can run your entire system self-hosted and the code for it is entirely OSS. Do I have that right?
With that said, our intent is to create the option to run the entire system self-hosted.
Hard to develop a SaaS service when the integration needs to have such close locality to your customers' systems.
Your comment is spot on - that's exactly what we've found. Authorization needs to be deployed right next to the application - no one is going to take a dependency on a SaaS developer API that is "the internet away", when authorization is in the critical path of every application request. That's why Aserto is packaged as a sidecar that you deploy right next to your application. The sidecar synchronizes state with the control plane, so authorization decisions are made with data that is locally cached.
It's also the case that authorization has to be done in the context of users that come from an identity provider. Aserto automatically syncs users from identity providers / directories (Okta, Auth0, etc).
Keycloak is a very solid product. The main aspect speaking in favor of Keycloak is its extensibility. Nothing beats it.
The problem with Keycloak is that people generally don't want to invest too much into learning it.
If anyone has already done an independent study of the ecosystem I'd love a link.