7 ms·

Aserto: Developer API for permissions and RBAC

114 points by vklmn 5y ago

apoland 5y ago
I've built my own authz too many times. The prospect of having a standard framework to do this is encouraging.
bradhe 5y ago
I'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!
- ogazitt 5y ago
  Thanks Brad! We're big fans of both Auth0 and OPA.
rschwabco 5y ago
Can't I just use Auth0 for authorization?
- ogazitt 5y ago
  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-permissions https://www.aserto.com/blog/oauth2-scopes-are-not-permission...
- kache_ 5y ago
  Auth0 is building something pretty cool akin to Zanzibar https://play.fga.dev/ https://play.fga.dev/
  - wereHamster 5y ago
    There are at least two startups which are re-implementing something like zanzibar. In my experience, RBAC is too simplistic for even not so advanced apps. For example, with RBAC alone you can't express «User X can edit object Y», if object Y is one of many objects in a collection. Zanzibar – and any system building on top of tuples (subject, relation, object) – can express that quite intuitively.
    - ogazitt 5y ago
      RBAC is simple to get started with, but indeed pretty limited. We tend to use the term because it's more recognizable than ABAC or ReBAC. The {subject,relation,object} tuples do provide a convenient way to express an ACL-based system. Most real-world systems we've encountered tend to have a combination of user-centric and resource-centric aspects to them. With an ABAC-style policy, you can easily enforce relationships like "user X can edit objects in project Y, and can read objects in project Z". In fact, the Aserto policy for Aserto [1] uses this style of authorization, without going "full-tuple". In fact, for many use-cases, the prospect of creating an ACL for every resource feels like a management nightmare for the folks we've talked to, and they typically have a "resource group" construct or hierarchy that they want to treat the same from an authorization perspective. Finally, in addition to the user model, Aserto has a resource model, and we're exploring evolving it more towards the tuple approach. [1] https://github.com/aserto-dev/policy-aona https://github.com/aserto-dev/policy-aona
      - wereHamster 5y ago
        Zanzibar has a notion of «User sets» to allow expressing conditions such as «File X can be viewed by (all users who can view Folder Y)» to avoid too much duplication in the rule sets. One challenge they had was to make resolving these rules not too slow, since that forms basically a graph (= graph traversal)
- janczukt 5y ago
  As an ex-Auth0 I was watching Aserto for a while - it is indeed elegantly designed to naturally pick up where Auth0 leaves you. I wish this was available when we were adding authorization to Fusebit APIs. But well, next startup...
  - ogazitt 5y ago
    Thanks for the kind words! Maybe next time you look at evolving your authorization model, we can chat :)
eatonphil 5y ago
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.
- kache_ 5y ago
  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 5y ago
    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 5y ago
  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 5y ago
    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.
sparsely 5y ago
This 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.
- viovanov 5y ago
  If the caller can authenticate with the services, I think you can write some rego that does something like this. I'm interested in what the flow looks like. Does the caller talk to A first to initiate this delegation?
- gertd 5y ago
  You can create rules which take in to account that there is a temporary grant, you do need to account for that somewhere in the form of accessible state. This could be achieved using the tenant level resource state, which is immediately updated and can be referenced from the rego rule.
dew2105 5y ago
Auth is a major challenge and pain point... and Aserto is really impressive. Love the open source vs. completely walled garden approach.
fabian2k 5y ago
This is probably a pretty stupid question, or at least based on some misconception of mine about this space. But I don't really understand how permissions as a service or API can work efficiently. If I request a single resource, of course this can work if I ask a second API on whether the request is allowed or not. But if I query a database for a list of items, to add access control I need to modify the database query. I can't just filter after the fact, it's too easy to cause pathological performance issues there e.g. if the user has only access to a very small subset of a large list of results. How does this work with a separate access control API that can't directly modify the database query?
- ogazitt 5y ago
  Great question. There are two scenarios that are relevant for authorization: 1. Gating the operation (whether it's retrieving a single resource, or creating / updating / deleting a resource). In this scenario, the application does need to call the authorizer before performing the operation on the resource, but the relationship between the authorizer and the application is at "arms length". 2. Filtering a list of resources. In this scenario, the authorization system can help you by running what in OPA is known as a "partial evaluation", which returns an abstract syntax tree. Your code would then walk that tree and insert the proper where clauses (if you're talking to a SQL back-end). As you mentioned, by necessity, your application needs to work more closely with the authorizer.
- jzelinskie 5y ago
  Disclaimer: I am a founder of Authzed (W21). Generally, this problem is called ACL-Filtering[0][1] and can be done in two ways: "pre-filter" and "post-filter". Sometimes you might even have to do both. If you decide to use a service/database for permissions, similar to SpiceDB[2], there are often specialized APIs for directly listing the entities a subject has access to in various ways. You can take these results and feed them into a database query to select only the authorized content. This doesn't have to just be a list of IDs, but can also be datastructures like bitmaps, effectively providing your database with a custom index for your query. Systems that implement some of the novel parts of the Zanzibar paper[3] can also enable you to cache these values in your database until your application performs an operation that invalidates the results. Filtering once you've queried all possible results from your database can also be more performant than you'd think, because you can amortize performance by lazy loading and performing permission checks in parallel. We have some pretty large systems that are purely using this strategy. The code for filtering can also be made extremely elegant because it can be hidden behind the iterator interface in whatever programming language you're using. [0]: https://docs.authzed.com/reference/glossary#acl-filtering https://docs.authzed.com/reference/glossary#acl-filtering [1]: https://authzed.com/blog/acl-filtering-in-authzed/ https://authzed.com/blog/acl-filtering-in-authzed/ [2]: https://github.com/authzed/spicedb https://github.com/authzed/spicedb [3]: https://authzed.com/blog/what-is-zanzibar/ https://authzed.com/blog/what-is-zanzibar/
claytongulick 5y ago
So much of authorization is context / application dependent, I'm struggling with this a bit. For example, I have a cluster of services. I allow access to some of them, for certain actions, based on whether the user is part of a patient's care team. That's very dynamic, I need to do a FHIR query to one of my services to determine that. Then there's a lot more logic, like what servicer / organization affiliation the user is part of, this is also a runtime lookup in a shared session state thing, etc... I just list all that as a basic example, there are so many things that are application specific that require runtime evaluation, it's hard for me to understand the benefit of writing all that in a different language, in a different place, where I can't use the libraries and utilities that are already part of the application.
- sizediterable 5y ago
  But what if your services are written in different languages from each other and they need to perform similar authz checks? Sure, each service might need be responsible for its own data fetching, but the actual logic over the data can be written in one common language (Rego) and have one single source of truth.
  - ogazitt 5y ago
    This is indeed one of the benefits of the policy-as-code approach. And Rego syntax is much easier to grok than other "-as-code" approaches (read: wall-of-yaml)
  - claytongulick 5y ago
    Well, I'm in exactly this situation right now. The approach I've taken is to implement my own application gateway using node-http-proxy. I use npm workspaces to share common functionality between all the node parts of the application, including the api gateway / reverse proxy. I configure the other services to trust a HTTP header that's injected in the api gateway (and explicitly deleted from incoming requests) that includes details about the user. For example, Apache Superset (and several other services) support the REMOTE_USER header. Honestly, doing this in a high-level language like NodeJS with node-http-proxy is even simpler to do and easier to read / audit than what I've seen in Rego, plus I get to use all the common utilities for dynamic service access, database access, etc... This borders on a "NIH" thing, but I think if you saw the actual implementation, it's even less complex than what I'm seeing from these examples. It took me a couple hours to throw together, it's easy to extend, and supports a multitude of authentication scenarios, including shared-session (which would be tough with Rego).

114 points by vklmn 5y ago

I've built my own authz too many times. The prospect of having a standard framework to do this is encouraging.

I'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!

ogazitt 5y ago
Thanks Brad! We're big fans of both Auth0 and OPA.

rschwabco 5y ago

Can't I just use Auth0 for authorization?

ogazitt 5y ago
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-permissions https://www.aserto.com/blog/oauth2-scopes-are-not-permission...
kache_ 5y ago
Auth0 is building something pretty cool akin to Zanzibar https://play.fga.dev/ https://play.fga.dev/
- wereHamster 5y ago
  There are at least two startups which are re-implementing something like zanzibar. In my experience, RBAC is too simplistic for even not so advanced apps. For example, with RBAC alone you can't express «User X can edit object Y», if object Y is one of many objects in a collection. Zanzibar – and any system building on top of tuples (subject, relation, object) – can express that quite intuitively.
  - ogazitt 5y ago
    RBAC is simple to get started with, but indeed pretty limited. We tend to use the term because it's more recognizable than ABAC or ReBAC. The {subject,relation,object} tuples do provide a convenient way to express an ACL-based system. Most real-world systems we've encountered tend to have a combination of user-centric and resource-centric aspects to them. With an ABAC-style policy, you can easily enforce relationships like "user X can edit objects in project Y, and can read objects in project Z". In fact, the Aserto policy for Aserto [1] uses this style of authorization, without going "full-tuple". In fact, for many use-cases, the prospect of creating an ACL for every resource feels like a management nightmare for the folks we've talked to, and they typically have a "resource group" construct or hierarchy that they want to treat the same from an authorization perspective. Finally, in addition to the user model, Aserto has a resource model, and we're exploring evolving it more towards the tuple approach. [1] https://github.com/aserto-dev/policy-aona https://github.com/aserto-dev/policy-aona
    - wereHamster 5y ago
      Zanzibar has a notion of «User sets» to allow expressing conditions such as «File X can be viewed by (all users who can view Folder Y)» to avoid too much duplication in the rule sets. One challenge they had was to make resolving these rules not too slow, since that forms basically a graph (= graph traversal)
janczukt 5y ago
As an ex-Auth0 I was watching Aserto for a while - it is indeed elegantly designed to naturally pick up where Auth0 leaves you. I wish this was available when we were adding authorization to Fusebit APIs. But well, next startup...
- ogazitt 5y ago
  Thanks for the kind words! Maybe next time you look at evolving your authorization model, we can chat :)

eatonphil 5y ago

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.

kache_ 5y ago
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 5y ago
  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 5y ago
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 5y ago
  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.

sparsely 5y ago

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

viovanov 5y ago
If the caller can authenticate with the services, I think you can write some rego that does something like this. I'm interested in what the flow looks like. Does the caller talk to A first to initiate this delegation?
gertd 5y ago
You can create rules which take in to account that there is a temporary grant, you do need to account for that somewhere in the form of accessible state. This could be achieved using the tenant level resource state, which is immediately updated and can be referenced from the rego rule.

dew2105 5y ago

Auth is a major challenge and pain point... and Aserto is really impressive. Love the open source vs. completely walled garden approach.

fabian2k 5y ago

This is probably a pretty stupid question, or at least based on some misconception of mine about this space. But I don't really understand how permissions as a service or API can work efficiently. If I request a single resource, of course this can work if I ask a second API on whether the request is allowed or not. But if I query a database for a list of items, to add access control I need to modify the database query. I can't just filter after the fact, it's too easy to cause pathological performance issues there e.g. if the user has only access to a very small subset of a large list of results. How does this work with a separate access control API that can't directly modify the database query?

ogazitt 5y ago
Great question. There are two scenarios that are relevant for authorization: 1. Gating the operation (whether it's retrieving a single resource, or creating / updating / deleting a resource). In this scenario, the application does need to call the authorizer before performing the operation on the resource, but the relationship between the authorizer and the application is at "arms length". 2. Filtering a list of resources. In this scenario, the authorization system can help you by running what in OPA is known as a "partial evaluation", which returns an abstract syntax tree. Your code would then walk that tree and insert the proper where clauses (if you're talking to a SQL back-end). As you mentioned, by necessity, your application needs to work more closely with the authorizer.
jzelinskie 5y ago
Disclaimer: I am a founder of Authzed (W21). Generally, this problem is called ACL-Filtering[0][1] and can be done in two ways: "pre-filter" and "post-filter". Sometimes you might even have to do both. If you decide to use a service/database for permissions, similar to SpiceDB[2], there are often specialized APIs for directly listing the entities a subject has access to in various ways. You can take these results and feed them into a database query to select only the authorized content. This doesn't have to just be a list of IDs, but can also be datastructures like bitmaps, effectively providing your database with a custom index for your query. Systems that implement some of the novel parts of the Zanzibar paper[3] can also enable you to cache these values in your database until your application performs an operation that invalidates the results. Filtering once you've queried all possible results from your database can also be more performant than you'd think, because you can amortize performance by lazy loading and performing permission checks in parallel. We have some pretty large systems that are purely using this strategy. The code for filtering can also be made extremely elegant because it can be hidden behind the iterator interface in whatever programming language you're using. [0]: https://docs.authzed.com/reference/glossary#acl-filtering https://docs.authzed.com/reference/glossary#acl-filtering [1]: https://authzed.com/blog/acl-filtering-in-authzed/ https://authzed.com/blog/acl-filtering-in-authzed/ [2]: https://github.com/authzed/spicedb https://github.com/authzed/spicedb [3]: https://authzed.com/blog/what-is-zanzibar/ https://authzed.com/blog/what-is-zanzibar/

claytongulick 5y ago

So much of authorization is context / application dependent, I'm struggling with this a bit. For example, I have a cluster of services. I allow access to some of them, for certain actions, based on whether the user is part of a patient's care team. That's very dynamic, I need to do a FHIR query to one of my services to determine that. Then there's a lot more logic, like what servicer / organization affiliation the user is part of, this is also a runtime lookup in a shared session state thing, etc... I just list all that as a basic example, there are so many things that are application specific that require runtime evaluation, it's hard for me to understand the benefit of writing all that in a different language, in a different place, where I can't use the libraries and utilities that are already part of the application.

sizediterable 5y ago
But what if your services are written in different languages from each other and they need to perform similar authz checks? Sure, each service might need be responsible for its own data fetching, but the actual logic over the data can be written in one common language (Rego) and have one single source of truth.
- ogazitt 5y ago
  This is indeed one of the benefits of the policy-as-code approach. And Rego syntax is much easier to grok than other "-as-code" approaches (read: wall-of-yaml)
- claytongulick 5y ago
  Well, I'm in exactly this situation right now. The approach I've taken is to implement my own application gateway using node-http-proxy. I use npm workspaces to share common functionality between all the node parts of the application, including the api gateway / reverse proxy. I configure the other services to trust a HTTP header that's injected in the api gateway (and explicitly deleted from incoming requests) that includes details about the user. For example, Apache Superset (and several other services) support the REMOTE_USER header. Honestly, doing this in a high-level language like NodeJS with node-http-proxy is even simpler to do and easier to read / audit than what I've seen in Rego, plus I get to use all the common utilities for dynamic service access, database access, etc... This borders on a "NIH" thing, but I think if you saw the actual implementation, it's even less complex than what I'm seeing from these examples. It took me a couple hours to throw together, it's easy to extend, and supports a multitude of authentication scenarios, including shared-session (which would be tough with Rego).