Evolving to Enterprise-Grade Permissions | Hacker News Reader

Evolving to Enterprise-Grade Permissions

benchling.engineering

26 pointssajithw8 comments

At the risk of making sweeping generalizations, the people who build permission systems tend to be very different from the people who sit at a desk and set permissions for people.

Those who build permission systems commonly think very deeply about the process and can hold tremendously complex permission systems in their head. The people who are tasked with setting permissions in the real world tend to view anything else as a more important part of their job to think about and tend to default to either granting permissions broadly so they aren't bothered again or granting permissions minimally so they aren't blamed for things.

A small number of well designed and well named roles is unfortunately commonly better in practice than a highly powerful and flexible fully configurable turing complete granular permissions management system.

(Benchling PM here)

As far as sweeping generalizations go, I think that's a pretty reasonable one :). I'd imagine that almost all of our users (including most lab admins who assign permissions) don't want to keep a complex permission system in their head.

What we've seen is that this system ends up leading to a small number of well-designed and well-named roles. Most users see the roles themselves ("DNA Designer"), but don't need to worry about exactly what the configuration behind it is.

Somebody needs to be aware of the powerful (although not quite turing-complete) configuration system, but what we've seen in practice is that it's usually one or two technical admins whose job it is to gather requirements from the different teams and figure out how to translate those into a few digestible policies that everybody else can assign.

We certainly didn't invent this model (it's basically RBAC), but we've found it's a good way to address the often-complex demands of a big pharma (where IP is crazy regulated from like, 3-4 angles) without taxing the individual scientists too much.

It may be too difficult to maintain fine grained permissions for each bespoke professional role, but it seems the investment could be worthwhile for large homogenous groups. Example: CSRs only need access to accounts relating to assigned, active cases.

The reasoning about only allowing additive permission is something I've had pretty strong opinions, and it's nice to see that other people agree with this. Permissions gets incredibly complicated very fast even in the best case, and any additional complexity can easily confuse users.

Their use case feels a bit too micro-managed for my taste, but that is certainly a matter of opinion. And if their customers demand this, it's hard to convince them otherwise. My preference is to handle certain more subtle cases like their "only DNA design team can edit sequences, but Research team can edit metadata" as a convention, not a hard rule enforced by the application. And if you have a good history of changes, it still allows for transparency about who edited what.

Interesting article and really close to what we’ll need to do at my company soon!

I wonder if there are any open-source projects that operate in this realm and provide an off the shelf solution to this.

I’m thinking that it could be something like a small server to store the policies and a few libs in various languages to interpret them.

This could or could not be tied to a user management system.

Gluu is possibly an off-the-shelf solution: https://www.gluu.org (I’m not deeply familiar with its authorization capabilities)

Awesomeness @adamfeldman, thanks for the pointers!

See also https://github.com/open-policy-agent/opa (lower-level building-block) and https://github.com/ory/keto (built on OPA)

Reply on news.ycombinator.com