-
-
Notifications
You must be signed in to change notification settings - Fork 13
Description
Ory solution to handle authorization is named Ory Keto. This solution is based on Google Zanzibar. The fact that we authenticate users on ory.sh has zero consequence on the choice of Ory Keto. Authentication in ory.sh is uncorrelated to authorization.
An alternative I know a bit (because it is used by old teammates, that's all) is OPA - Open Policy Agent.
AWS has open-sourced its internal system, now called Cedar.
Interesting reads:
- https://authzed.com/blog/what-is-google-zanzibar
- https://permify.co/post/opa-vs-google-zanzibar/
- https://www.cedarpolicy.com/blog/the-case-for-less-expressiveness
- https://www.permit.io/blog/opa-vs-cedar
- probably https://www.gartner.com/en/documents/5624191 (but I don't have a Gartner access)
And more generally, would we like to run a RBAC, ABAC, PBAC, ReBAC model (... sic ...).
My personal feeling is that even after 1 hour of reading, I still don't get how you are supposed to model things in Keto / Zanzibar. Quite simple conditions like "do not allow access if user does not has MFA" or "allow access only from 8am to 5pm" seems overly complex to integrate, or I just don't get it. I'm quite concerned this will be way too hard to master.
On the other end of the spectrum, I'm naturally skewed towards Cedar since I used it for quite a long time in AWS. It has quite a lot of limitations (you cannot model very complex things) but is pretty easy to read and sufficient in 99% of the cases. And even with this simplicity you sometimes achieves to fall in a trap (where you assumed you've granted something but something else happens). I'm at least very concerned by complex languages which allow to model "anything" precisely because of their unlimited nature which can lead to stuff very hard to analyze.