Hacker News new | ask | show | jobs
by jsiaajdsdaa 1539 days ago
In the enterprise system I design/implement/maintain, I currently have a (!)limited set of roles for my main business logic service.

Each task in that system has an accompanying set of roles that are authorized to execute it, and essentially that authorization happens at the controller level and is "at the edge" of the application instead of in the business logic itself.

Is there a benefit I could gain from Oso? I will read what you've provided.

1 comments

Honestly, if your authorization needs are coarse enough that you can (a) handle it as middleware at the controller level, and (b) mostly just rely on roles, then you're probably in a good place to keep going with that! It avoids a lot of the complexity of centralization.

Where we normally see people considering Oso is when the model gets more complex, or the data requirements get larger. E.g. when you introduce new features like user groups, projects, or sharing, then the amount of logic + data you need to share between the services grows beyond what's sustainable.

If you're current system is working for you, I'm not going to try and tell you otherwise! If that changes though, let me know ;)