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