Aserto: Developer API for permissions and RBAC
1–10 of 53 posts
Re: Aserto: Developer API for permissions and RBAC
#2I've been following Aserto for a while actually, really excited to see this development. Makes a great compliment to Auth0. Also the stuff they're doing for the OPA ecosystem is awesome!
Re: Aserto: Developer API for permissions and RBAC
#3Can't I just use Auth0 for authorization?
Re: Aserto: Developer API for permissions and RBAC
#4I've been following Aserto for a while actually, really excited to see this development. Makes a great compliment to Auth0. Also the stuff they're doing for the OPA ecosystem is awesome!
Thanks Brad! We're big fans of both Auth0 and OPA.
Re: Aserto: Developer API for permissions and RBAC
#5Can't I just use Auth0 for authorization?
Auth0 is a great developer API for authentication, and Aserto picks up where Auth0 leaves off. The "contract" between the authentication system (Auth0) and the authorization system (Aserto) is a signed JWT.
You can get away with very simple access control using scopes embedded in a JWT token, but that approach runs out of room pretty quickly [0]
With Aserto, you can write authorization rules that are evaluated for every application request, and reason about the user attributes, the operation, and any resource context that is involved in the authorization decision.
[0] https://www.aserto.com/blog/oauth2-scopes-are-not-permission...
Re: Aserto: Developer API for permissions and RBAC
#6There 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.
Re: Aserto: Developer API for permissions and RBAC
#7There 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.
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.
Re: Aserto: Developer API for permissions and RBAC
#8Can't I just use Auth0 for authorization?
Auth0 is building something pretty cool akin to Zanzibar
Re: Aserto: Developer API for permissions and RBAC
#9This looks so cool. I've always wanted something like this, especially being able to write the policies in Rego. I can't work out if it supports delegation though, i.e. service A temporarily allows service B to access a resource which normally only A has access to.
Re: Aserto: Developer API for permissions and RBAC
#10There 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.
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.
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).