
Evolving to Enterprise-Grade Permissions - sajithw
https://benchling.engineering/evolving-to-enterprise-grade-permissions-493eac166449
======
yodon
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.

~~~
norseboar
(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.

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

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

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

~~~
flevours
Awesomeness @adamfeldman, thanks for the pointers!

