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
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.
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]
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.
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
Or from Permit.io here :) - we support OPA, Cedar, as well as Amazon Verified Permissions, and we'll be coming out with more soon.
Both in Permit.io and in OPAL 1
Graham from OSO (gneray) - just didn't see the recent news, I guess we'd need to speed up OSO support as well ;-)
True a gating reverse proxy isn't a new idea- but combining it with frontend only login, policy as code, and secrets injections from a vault to produce authorization you can use seamlessly from the frontend kinda is ;-)
:D Truly?
So does that mean you won't use any cloud service (e.g. AWS, GCP, Azure) ? And no Authentication services (e.g. Auth0, AWS Cognito, Firebase)? ...
In a sense you do own it, you just delegate it, and thanks to JWT and JWKs you control the identity flow.
Meaning, you don't have to physically be the guard at the door, to know your door is guarded. And you can use passports and well formed policies (ideally as code) to communicate to your guards who to let in, when, and how.
You are correct (As this is a generic component), but kinda missing the point ;)
In the backend - you don't need this - there are already solutions you can consume for authorization (OPA, AWS Cedar, Permit.io, ...)
But in the frontend there is nothing you can use, that's what FoAz aims to solve - shift security left to the frontend, reducing dependency on backend engineering.
Of course you need identity (FoAz uses JWTs from authN solutions - can also be your VM (if it produces a JWT as it's magic link process)) , but Authorization is another step on top.
e.g. You are [email protected] (or some other verified identity), I know you, but how many SMS messages should I allow you to send via Vonage or Twilio when you click the button in the app? Managing that quota is an example of authorization.