31–40 of 53 posts
Can't I just use Auth0 for authorization?
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...
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 quer…
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.
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.
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.
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 quer…
If you are using Postgres (or YugabyteDB) then you can use row level security for that.
Using your DB's row-level security for data filtering is definitely complementary to API authorization.
[0] https://www.aserto.com/blog/modern-authorization-requires-de...
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 quer…
As others have mentioned, authorization often requires both a single method to authorize "can the user perform this action on this resource" as well as more flexible versions like "what are all the resources this user can perform this action on". That's one part of why authorization is hard, I wrote an article on this a little while ago [1]. At Oso (disclaimer: I'm the CTO), we solve this by turning authorization logic into SQL [2].
Supporting those APIs in a generic service definitely turns up the difficulty level -- you no longer have a single database to query.
The thing is, if you have multiple services, you might already be in that situation. If I need to query another service to ,e.g., find what projects a user belongs to, and then need to go combine that with data in my database, I'm going to need to start worrying about how to do that efficiently. In those situations starting to centralize that data + logic starts making sense -- we talk about this in [3]. So now there's a bunch of companies with different takes on how to best solve this, including Oso.
---
I feel bad about self-promoting so many links here... but we're passionate about this subject so we've been writing a lot about it!
[1]: https://www.osohq.com/post/why-authorization-is-hard
[2]: https://www.osohq.com/post/authorization-logic-into-sql
[3]: https://www.osohq.com/post/microservices-authorization-patte...
Earlier quoted context omitted.
If you are using Postgres (or YugabyteDB) then you can use row level security for that.
Authorization is really about "defense in depth". In a ZTA model, your access proxy, authentication system, API gateway, application middleware, and data layer all provide additional levels of protection [0]. Using your DB's row-level security for data filtering is definitely complementary to API authorization. [0] https://www.aserto.com/blog/modern-authorization-requires-de...
Earlier quoted context omitted.
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.
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 relationship…
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 quer…
Instead, we went with Casbin (microsoft research) because it can push to your DB (including multi-tenant-sharing if you scale) and a legit modern policy engine - A(R)BAC, ACL, etc. Definitely warts, but pretty close to what I'd hope architecturally, meaning a clear path to prettier UIs, plugging into automatic SMT solvers/verifiers, etc, and till then, pretty easy from whatever backend lang + SQL DB you use.
Long-term, stuff like row-level security in your SQL / metadata store makes a lot of sense (people pointing that out in the thread below), but RLS is still awkward in practice for even basic enterprise RBAC/ACL policies. Until then, Casbin-style architectures are the equivalent of a flexible external policy decision point with the actual compute still being pushdown to wherever you want, including the DB: win/win.
I wish the VC money went this way instead, but I see why $ goes to simpler "google for everyone else" pitches, so here we are :(
Earlier quoted context omitted.
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 relationship…
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)
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 quer…
We've passed on most of the google-pointing technologies in this thread precisely because of that architectural footgun Instead, we went with Casbin (microsoft research) because it can push to your DB (including multi-tenant-sharing if you scale) and a legit modern policy engine - A(R)BAC, ACL, etc. Definitely warts, but pretty close to what I'd hope architecturally, meaning a clear path to prettier UIs, plugging int…
We chose a more pragmatic approach with Aserto. We believe that most authorization problems can be expressed as a combination of rules and data. A system that is 100% rules or 100% data isn't pragmatic.