The never-ending product requirements of user authorization | Hacker News Reader

The never-ending product requirements of user authorization

alexolivier.me

67 pointsCSDude24 comments

For anyone who wants to learn what a good authorization system looks like take a look at Tailscale's recent blog post: https://tailscale.com/blog/rbac-like-it-was-meant-to-be/

Really, if you're going to be selling to enterprise clients, you want an attribute-based authorization system. If you need help designing it, talk to your IT/Devops/SRE teams, they'll be able to complain about bad auth systems and what they'd want in an ideal world.

We're in the middle of redesigning our access control layer. Following the requirments of our platform and the need for simplicity we ended up with an almost identical system.

Thanks for sharing the article it was a good read and validation.

Keycloak supports Attribute-based access control (ABAC) along with other modes.

Interesting project, the post resonated, there are more architectural considerations here: https://docs.cerbos.dev/cerbos/0.6.0/index.html

Even as a PdM, I've felt the pain here. Usually it manifests as, "we can't solve this user problem because the authorization controls to make this work are too complex."

Looking forward to a world where this is a solved problem.

Disclaimer: Im friends with the author of the post.

CEO of Cerbos here - we'd love to hear about the other headaches everyone has faced. Authorization as we know it, isn't core to anyone's roadmap and we want to make it as easy as possible to meet the all the crazy requirements.

We are building out examples of how to solve common use cases which you can find on https://cerbos.dev/

Will you build integration libraries or SDKs for the common programming languages and flows? In my case I'm with C# and use the dependency injection to get an instance of a service that verifies the user requests.

We are working through the priority list of SDKs. You can find them all on https://github.com/cerbos/

Node, Java and Go are already available and other languages are coming very soon.

The architecture image on Cerbos makes it look like you pull stateful attributes from the primary sources (AD?). That doesn’t seem like it will scale well compared to cache or stateless designs.

What TPS do you support? Response latency?

Cerbos is stateless by design and was in fact born out of our experience of running services that handled 100k+ RPS with millisecond latency. It does not pull any data from other external sources, rather all the information required to make a decision is passed in the call to check if a request is authorized. Cerbos makes decisions based on the policies and the context provided at the request time. In most cases, the context is already in the services making the check. (it knows which user/principal and the resources that are being accessed).

Because Cerbos makes decisions based on contextual data, caching is not very straightforward to implement. Response times are pretty good even without caching. We are constantly working on trying to find ways to make things quicker all the time and that may or may not involve caching.

We are working on producing a reproducible and realistic benchmark for public consumption. In our internal tests, the 95th percentile response times have been always under 10ms. Of course, this depends a lot on how complex the policies are and how much data there is to process.

Related and very interesting: https://news.ycombinator.com/item?id=28543457

Good to see more things happening in this space.

Access control is heart and mind of any business logic, is your backend system itself. You cannot outsource it, this is absurd.

The main question is "what if it goes wrong?"

We wholeheartedly agree and that is why we are building an open-source, self-hosted option which you can run yourself, inside your own network with strong audit and version control of policies. There are no calls to the mothership or anything like that. Everything is self-contained and your downtime is entirely yours to manage. Having a traffic spike? Just spin up another Cerbos instance immediately. You don’t have to contact us, pay any extra fees and go through a support channel to increase your capacity.

Isn't this just reinventing OAuth?

OAuth already has grant_type and "scope" to cover different devices, flows and permissions.

Um no. The issue is authorization is a million tentacled octopus that reaches into every crevice of your app, and if the app is built out of multiple services, auth reaches into those. The thread someone just linked from yesterday (https://news.ycombinator.com/item?id=28543457) and the article it points to is sales-y but gives a picture of some of the issues.

Author of the article here.

This is a very common question we get. OAuth is great for when the permissions can be modelled as a set of roles/scopes which apply uniformity. Where that breaks down as described in the article is when there needs to be more context involved in the authoriZation - beyond simple roles from your chosen autheNtication provider.

The fact that OAuth isnt mentioned a single time in the article is glaring. You should at least have a paragraph like "why not just use OAuth?" where you answer that question. Otherwise it seems youre avoiding the question on purpose, as these two items are clearly in the same space.

Thanks for the feedback - are are working on adding more comparisons of technologies onto https://cerbos.dev and will certainly make sure to include OAuth

The auth in OAuth stands for authentication. This is authorization.

Not according to the OAuth 2.0 RFC, which is titled "The OAuth 2.0 Authorization Framework": https://datatracker.ietf.org/doc/html/rfc6749

OAuth is an authorization framework.

Please can you help me on it, I want it

What help do you need? It's free and open source - https://cerbos.dev/

You can find all the technical documentation here: https://docs.cerbos.dev

Reply on news.ycombinator.com