[eatonphil]

There are a lot of new-ish products in the last 5 years in the auth/identity space. I have been meaning to dig into them: Kanadm, Keycloak, Ory, SuperTokens, Oso, FusionAuth, CAS, maybe Authzed. I hadn't heard of Aserto yet, adding them to the list. Although I'm most interested in OSS products and Aserto looks like it is hosted-only.

If anyone has already done an independent study of the ecosystem I'd love a link.

[ogazitt]

Aserto is based on a few open source projects: OPA [1], policy CLI [2], and Open Policy Registry [3].

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/

[2] https://github.com/opcr-io/policy

[3] https://www.openpolicyregistry.io/

[eatonphil]

Being based on open source projects doesn't mean too much (Youtube is written in Python, so it's based on open-source). Having a consistent language (OPA) does mean something.

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?

[ogazitt]

You're right that the control plane currently is not OSS. Most people we talked to when we first embarked on the journey said that it was critical for the authorizer to run locally (and be OSS), but they preferred to not have to operate the control plane.

With that said, our intent is to create the option to run the entire system self-hosted.

[eatonphil]

Thanks for clarifying!

[kache_]

The biggest competitor in this space: build your own

Hard to develop a SaaS service when the integration needs to have such close locality to your customers' systems.

[ogazitt]

Hi, this is Omri, co-founder of Aserto.

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).

[itsronenh]

Aserto takes a hybrid approach. It runs a hosted control plane where you configure your user-directory, authorization policies, etc. But the authorization logic itself can run alongside the application that uses it, ensuring high availability and low latency.

[rad_gruchalski]

This can be done with Keycloak Authorization Services and custom logger. Keycloak loggers can be essentially anything, and they can listen and react to any kind of event happening inside. For example: policy create, update, delete. Those events can be forwarded to whatever needs to build your OPA policies.

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.