The approach is like the approach we took in what is now a 20 year old web application, we tried to some extent model it on file permissions, and the REST pattern of noun + CRUD verb, but that wasn't always easy.
we hit a couple of hurdles along the way:
We found that we needed to always evaluate all access based on task and data, you couldn't assess those two separately - this enabled uses such as:
a couple could give each other access to read each other's data, but not sign on each others behalf. but if someone was incapacitated and some one was given power-of-attorney, the POA could sign on a different user's behalf.
We tried to control all the permissions via groups, and built a UI to maintain the groups and allocations, but the UI never got the attention it needed
We needed be able to freeze out tasks, so we had to build grant and deny permissions, where the deny always overruled the grant.
We tried very hard to model all the permissions around a
We made the process of setting up new permission types too difficult, developers just reused existing task permissions, and then none of the permissions really meant what we thought it meant because the code that used certain tasks for the access check, did something very different to the name of the permission.
Mostly it's worked fine, it got complex because the needs were complex, and it's now getting ripped out for active directory.
Thanks for your response! A lot of the issues and solutions you mentioned remind me of my time in past roles. More companies deal with authz related issues than we think, yet there aren't many products available that solve these long-term operational problems (UI, managing existing/new permissions over time, etc). Most solutions are just basic DIY libraries, although services like Warrant (https://warrant.dev/) are now becoming popular as engineering teams realize the complexity of solving/maintaining authz for the life of a software product.
To your point, authz is rarely a business's core product, so many in-house solutions don't get enough attention, and tend to become a big source of friction for engineering and product teams as they age. In my experience, this can slow down teams considerably or reduce code quality over time, which is why I'm excited to help devs find & build better solutions.
I'm glad you enjoyed my post, and I look forward to sharing more about building robust authz!
The approach is like the approach we took in what is now a 20 year old web application, we tried to some extent model it on file permissions, and the REST pattern of noun + CRUD verb, but that wasn't always easy.
we hit a couple of hurdles along the way:
We found that we needed to always evaluate all access based on task and data, you couldn't assess those two separately - this enabled uses such as: a couple could give each other access to read each other's data, but not sign on each others behalf. but if someone was incapacitated and some one was given power-of-attorney, the POA could sign on a different user's behalf.
We tried to control all the permissions via groups, and built a UI to maintain the groups and allocations, but the UI never got the attention it needed
We needed be able to freeze out tasks, so we had to build grant and deny permissions, where the deny always overruled the grant.
We tried very hard to model all the permissions around a We made the process of setting up new permission types too difficult, developers just reused existing task permissions, and then none of the permissions really meant what we thought it meant because the code that used certain tasks for the access check, did something very different to the name of the permission.
Mostly it's worked fine, it got complex because the needs were complex, and it's now getting ripped out for active directory.