Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Aserto: Developer API for permissions and RBAC

aserto.com

Post reply on HN
Print view View original

41–50 of 53 posts

Re: Aserto: Developer API for permissions and RBAC

#41

Post by gertd »

jzelinskie wrote: post #24
fabian2k wrote: post #21

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…

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…

So the idea is that you create a candidate set of resource keys from the permission system and join that with the external database and / or use it as a post filter?

Re: Aserto: Developer API for permissions and RBAC

#42

Post by ogazitt »

samjs wrote: post #35
fabian2k wrote: post #21

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…

It's actually a pretty great question! 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…

Welp, you know you're solving a hard problem when two other founders drop links in your HN thread :)

More seriously, I agree that there are a number of challenges, and different use-cases tend to require different approaches. Over time, we think there will be a set of common patterns that emerge, which will help the industry move towards a more consistent set of authorization experiences. And that will be great for everyone.

Re: Aserto: Developer API for permissions and RBAC

#43

Post by claytongulick »

itsronenh wrote: post #29
claytongulick wrote: post #22

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 us…

This goes straight to the core of what makes authorization in complex applications such a challenge. You hit the nail on the head when you say that authorization in inseparable from each application's unique circumstances. At the most abstract level, an authorization decision is an answer to the question "is an identity (user, service, computer, etc.) allowed to perform an action on a resource?". Each one of these co…

I totally get the benefits, the part I'm struggling with is the real-world details.

Like, the amount of effort it would be to put in application logic in order to determine attributes that would then be put on to the profile would be more than that which would be required to just have auth native in the code.

Then there's the problem of keeping those attributes in sync with the application as things change.

Then there's the problem of debugging when things go wrong - instead of being able to inspect the application state and determine the issue, now I have two places and different processes for issue resolution.

I'm not talking about this in a hypothetical sense - I've tried this before. All sort of declarative rule based systems, and integration with Auth0 with attributes stored as part of the Auth0 profile, etc...

After doing it and balancing the benefits, I've found that having well-architected code base with auth as a separate concern, but embedded within the native code (as a separate class/service/module/etc... is more effective and less work with better performance characteristics.

Obviously this doesn't apply to every situation, I can think of several scenarios where third-part auth would work very well, I just don't run into them a lot.

Re: Aserto: Developer API for permissions and RBAC

#44

Post by samjs »

ogazitt wrote: post #42
samjs wrote: post #35

Earlier quoted context omitted.

It's actually a pretty great question! 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…

Welp, you know you're solving a hard problem when two other founders drop links in your HN thread :) More seriously, I agree that there are a number of challenges, and different use-cases tend to require different approaches. Over time, we think there will be a set of common patterns that emerge, which will help the industry move towards a more consistent set of authorization experiences. And that will be great for e…

Indeed ;) https://news.ycombinator.com/item?id=28559608

Re: Aserto: Developer API for permissions and RBAC

#45

Post by claytongulick »

sizediterable wrote: post #26
claytongulick wrote: post #22

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 us…

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.

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

Re: Aserto: Developer API for permissions and RBAC

#46

Post by ogazitt »

wereHamster wrote: post #37
ogazitt wrote: post #30

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)

Yes, flattening the graph is essential to getting reasonable performance.

A separate (difficult) problem is to keep all the tuple data consistent with the data in your store (often these contain duplicate info).

Re: Aserto: Developer API for permissions and RBAC

#47

Post by ogazitt »

kache_ wrote: post #39
wereHamster wrote: post #37

Earlier quoted context omitted.

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)

Reading the Zanzibar paper is actually how I learned about how powerful of an optimization technique denormalization could be

It's definitely a good paper :)

Denormalization has been around since Date/Codd invented 6NF and relational databases, and then we all realized that most applications have to precompute some joins in order to execute in a performant fashion. In SQL Server we used to call them "materialized views".

Re: Aserto: Developer API for permissions and RBAC

#48

Post by ogazitt »

claytongulick wrote: post #45
sizediterable wrote: post #26

Earlier quoted context omitted.

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.

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…

That approach could definitely work if all you need for authorization is context about the user. Sometimes that context does get large, and it's hard to put it all in an HTTP header. This is a common problem for SaaS products that bake a bunch of scopes into their JWT and put it into the HTTP Authorization header. We've helped some of our customers unroll that approach and create an explicit authorization service that the app calls.

Also, once you start incorporating resource-specific information in your authorization decisions, this approach starts to break down. The gateway could be made to understand resource-specific information, but then you're essentially moving the problem from the application to the gateway. And typically you want your API gateway to make forward/block decisions quickly.

Happy to chat about your use case! You can find me at @omrig / omri at aserto dot com.

Re: Aserto: Developer API for permissions and RBAC

#49

Post by gertd »

gertd wrote: post #41
jzelinskie wrote: post #24

Earlier quoted context omitted.

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…

So the idea is that you create a candidate set of resource keys from the permission system and join that with the external database and / or use it as a post filter?

@jzelinskie care to respond, I am really interested in the answer?

Re: Aserto: Developer API for permissions and RBAC

#50

Post by DandyDev »

samjs wrote: post #35
fabian2k wrote: post #21

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…

It's actually a pretty great question! 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…

Hey samjs, we've been using Oso at Source.ag for a month or so, and we're really happy with it! Precisely the fact that you solve authorization on a resource level and implement filtering on the DB level, makes it super useful!

The biggest gripe we have, is lack of support for SQLAlchemy 2.0 style queries and lack of support for DB & Python enums as role names

We had a chat with Graham who told us about your upcoming cloud offering. Looking forward to that!

Post reply on HN