4 ms·

This model makes a ton of sense for abstracting away individual file permissions to higher level RBAC concepts. I really like the concept that an expandable set

by er4hn 5y ago

This model makes a ton of sense for abstracting away individual file permissions to higher level RBAC concepts. I really like the concept that an expandable set of tags gets compiled down to lower level ACLs The follow up question I have is: who decides the group members? That becomes the new point of failure. In the examples here it appears to be HR. How can one secure deciding those group members so that say, Joe in HR doesn't install some malware, adds himself to Eng + Executive, and then go wild?

lmeyerov 5y ago
It sounds like an incomplete model if groups aren't themselves controllable objects. I think they are punting to host MAC for that? Fun factoid: Even if roles aren't explicitly compiled to ACLs -- which is really an arbitrary implementation artifact, not a design requirement -- a lot of ABAC systems (and their policies) like these can be provably converted on-the-fly. This matters bc (1) it frees up implementations to be things like in-DB RLS policies (so you don't need to leave the DB for authorization decisions, as recent Google-clones and auth startups slow your app down with), and (2) you can send the policies (vs ACL 'binaries') to friendly verifiers like Z3 for fast and easy interactive analysis/querying/auditing/verification. We wrote a paper showing XACML -> BDDs for that ("Margrave") in what now feels like the stone age, and AWS more recently redid it for IAM via Z3. IMO, getting this into postgres could be a pillar for a really awesome DBaaS/PaaS startup: imagine Django or Rails w built-in scale-to-zero multitenancy & rich collaboration, which are normally a PITA
longcommonname 5y ago
We wrote a custom controller that manages Google workspace and github groups. This allows us to use those groups for identity. Changes to those groups happen solely by the PR process. HR, is only responsible for adding them to the single group which allows single sign on access not does not give any other access.
jbjohns 5y ago
The article kept saying HR was responsible but I don't understand why this wouldn't be split organisationally. A manager knows who is on their team (and when they leave), it seems to me it would make the most sense to split the "groups" into teams and make the managers responsible for keeping their group up to date.

by er4hn 5y ago

lmeyerov 5y ago

It sounds like an incomplete model if groups aren't themselves controllable objects. I think they are punting to host MAC for that? Fun factoid: Even if roles aren't explicitly compiled to ACLs -- which is really an arbitrary implementation artifact, not a design requirement -- a lot of ABAC systems (and their policies) like these can be provably converted on-the-fly. This matters bc (1) it frees up implementations to be things like in-DB RLS policies (so you don't need to leave the DB for authorization decisions, as recent Google-clones and auth startups slow your app down with), and (2) you can send the policies (vs ACL 'binaries') to friendly verifiers like Z3 for fast and easy interactive analysis/querying/auditing/verification. We wrote a paper showing XACML -> BDDs for that ("Margrave") in what now feels like the stone age, and AWS more recently redid it for IAM via Z3. IMO, getting this into postgres could be a pillar for a really awesome DBaaS/PaaS startup: imagine Django or Rails w built-in scale-to-zero multitenancy & rich collaboration, which are normally a PITA

longcommonname 5y ago

We wrote a custom controller that manages Google workspace and github groups. This allows us to use those groups for identity. Changes to those groups happen solely by the PR process. HR, is only responsible for adding them to the single group which allows single sign on access not does not give any other access.

jbjohns 5y ago

The article kept saying HR was responsible but I don't understand why this wouldn't be split organisationally. A manager knows who is on their team (and when they leave), it seems to me it would make the most sense to split the "groups" into teams and make the managers responsible for keeping their group up to date.