For the last three years, we have all seen a huge spike in developers implementing fine-grained authorization. Whether they choose the Google Zanzibar implementation or the OPA/Cedar policy approach, it has become a fundamental security and product requirement.
While trying to provide the best developer experience of implementing FGA with Permit.io, we saw developers use our APIs to build the experiences for request access and approval flows over and over again. Hence, we decided to take it a step further and launch a new product on top of the Permit.io platform - Permit Share-If.
"Permit Share-if" is a suite of prebuilt, embeddable UI components. They provide fully functional access control and allow developers to create and embed custom interfaces such as user management, audit logs, access requests, operation approval flows, and more.
You've probably seen access-sharing components (E.g., Requesting to edit a document, viewing a widget in a dashboard, or submitting a wire transfer for approval) a million times before. Now, you can implement them with just a few lines of code, providing the best FGA experience for your users.
Give them a try! Would love to hear your thoughts on this new release!
Hi!
Fair point. We got two articles coming this month: RBAC vs ReBAC, and RBAC vs ReBAC vs ABAC - we'll post those here / in the article itself when ready.
For now, in short:
RBAC (Role based) is a simple identity to role to permission mapping.
ABAC (Attribute based) maps conditions on attributes to to permissions (technically can implement anything - mostly used for things like time based, quotas, location, etc.)
ReBAC (relationship based) maps relations between identities and resources to permissions (e.g. if a user is related as an owner to a folder, and the folder contains a file, the user is the owner of the file) - commonly used for resource and organization hierarchies
Jimmy I truly think you're awesome (And so is SpiceDB), but the irony here stands out:
"it presents opinion without any evidence or examples to justify the claim and concludes it as fact"
You mean stuff like:
1) "SpiceDB, the most mature open source project inspired by Zanzibar" (though I'd vouch for that one)
2) " it is necessary beyond a particular scale which is well beyond the point at which policy engines typically fall over."
3) "Zanzibar is novel because it is fundamentally designed to be ran at the edge"
4) "we recently managed to scale SpiceDB to >1M requests per second with 100B relationships while maintaining a 5ms p95 measured at the client application" - you should bundle that statement with you need to set it up within your own VPC for it to be fair.
5) "The claim that you absolutely need a service to run a Zanzibar system is a provably false claim based on the number of clusters in the wild running SpiceDB or Ory's Keto project" - how many clusters? :)
Re: "This article conveniently leaves out how other systems get data to the edge while still keeping it consistent for their authorization logic"
The article actually does mention OPAL [0]
Your critique of my comment is quite fair; we're both guilty of making claims, but not including all the supporting evidence for brevity's sake. I think we can both agree that everyone working in this space is doing awesome work and bringing authorization the attention that it's sorely needed.
In Zanziabr - The article refers to OSS implementations like SpiceDB or Ory.
It's a follow-up to a more in depth article (1), trying to be a lighter read starting point.
It refers to Zanzibar as a "graphical" system, which I think was the first thing that snagged me on this. Your post does too; I assume this is a language snag? "Graphical" doesn't connote "graph-based" in American idiom, but rather "visual".
I don't think your writeup really captures OPA vs. Zanzibar especially well either, for the reasons given by the SpiceDB person upthread. It just sort of defines away the problem Zanzibar is trying to solve, while claiming that Zanzibar-type systems aren't deployable at the edge --- which is pretty clearly not true?
Re: "Graphical" - I can see how that would have that effect :)
To be fair it doesn't really say that, it reads:"Graph-based authorization systems utilize a graphical representation to illustrate relationships between users and resources"
Still, I think Daniel (post author) could have picked better phrasing - I'll ask him to change it.
> "while claiming that Zanzibar-type systems aren't deployable at the edge"
For most companies it's extremely impractical; and for a developer (Audience of this article) that simply wants to add performant permissions to their without embarking on a whole devops adventure it's as good as so.
Founder of Permit.io here- cool that this article grabbed some love.
For those of you not sure which is the best from the article- Permit combines all 3 together.
- OPA/REGO or Cedar at the edge, for quick efficient and zero latency policies
- And Zanzibar at the cloud control plane to manage the overall picture and relationships
Hi jzelinskie, Or from Permit here -
The overall tone of your reply here reads as furious to me ,so I'd like to apologize for offending you, I tried to provide a balanced analysis here- and I think you'd agree it's a tough topic to cover - especially in a brief manner.
I will say, I'm a big fan of your work at Authzed and SpiceDB, and while I think we probably don't see eye to eye on some topics like latency (e.g. I don't think same data-center is comparable to same node; or enough for realtime applications) ; I often recommend people to review and even use SpiceDB, it's my favorite open implementation of Google Zanzibar. I wouldn't call it a strawman at all in the context here - but rather a champion leading the charge.
I do think in the end of the day, there's much to be said about combining policy-as-code at the edge with graph in the cloud - my intention is to bridge the two (with an event-driven channel like https://github.com/permitio/opal)
Again, sorry if I didn't do a good enough job in portraying SpiceDB in the article, and I'd be happy to talk more about the subject.
BTW another differentiator we offer- is our low-code policy editor that write Rego or Cedar directly into Git for you (And your non-technical team members)
Supports RBAC, ABAC - and next month ReBAC
