orweis

Nice! Thanks for the share - I'm Or one of the founders or Permit.io. Happy to answer any questions.

Thanks a ton for the mention, and hope you like it. If you haven't also check out our video: https://youtu.be/JMzr21rnBes

Fine-grained authorization is becoming a staple, we hope to make not just building but also using it a breeze.

Or Weis, CEO at Permit.io here.

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

Agree 100%. <3 And as I told Joey many times - I'd love to collaborate more with you as well.

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]

[0] https://www.permit.io/blog/introduction-to-opal

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.

- 1: https://www.permit.io/blog/zanzibar-vs-opa

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

That's exactly what OPA does (Datalog), and what OSO do (Prolog)

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

https://docs.permit.io/features/policy-editor/editor-overvie...

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 ;-)

1 - https://docs.opal.ac/tutorials/cedar

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 ;-)

As asafc mentions, and as noted in the RFC (https://foaz.io/standard/RFC#foaz-service-reshapes-requests-...) - " Optionally the policy itself could be used to reshape the request." - the policy engine can be used to adjust the api call

: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 Dave@customer.io (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.

That sounds more like Authentication (verify identity) than Authorization (decide specifically what they are allowed to do per request), no?

Yep, checkout the BYOD page: https://foaz.io/use-foaz/byod Reverse-proxy + Policy-as-Code-Engine + Secrets Vault == FoAz

It's actually a good question :) It is the backend - but a generic backend as opposed to a specially tailored open per case.

To clarify - FoAz is frontend only - like Serverless has no servers :D

The idea is that as a FE developer you can consume this as a generic service once and for all, without constantly going back to backend and devops to set up glue code routes.

Feel free to follow up with more questions, especially if I wasn't clear enough

Hi HackerNews, Or from permit.io here, happy to discuss and answer questions here about the concept of FoAz and its RFC.

I agree with you re:"I wouldn't say Cedar is directly competitive as SpiceDB" - I think Zanzibar and SpiceDB in particular can work well together with Cedar / OPA. By syncing SpiceDB via OPAL[0] into edge nodes with Cedar-agents[1].

[0] https://github.com/permitio/opal

[1] https://github.com/permitio/cedar-agent

Hi Dang, apologize- we didn't plan anything here - simply a few friends / supporters in our community that were a little too eager to help. If we do post again, I'll figure a way to calm the enthusiasm. Also sorry fro the late reply - different timezones.

Hi, you can see a sneak preview of how approval flow interactions would look in this video here (https://youtu.be/2d4TwyvBh8M?t=6) As for best practices - checkout this talk I gave at OWASP- https://youtu.be/A5adHlkmdC0. Message us on our slack community (https://bit.ly/permit-slack) for early access to the feature.

In general, Permit allows you to switch over from an existing solution pretty easily. We had a company completely migrate their RBAC solution to using Permit with one dev over the course of less than two weeks. If you need any help in doing that, we’d be happy to assist (https://bit.ly/permit-slack).

Check out this example: https://youtu.be/-W-79h7FJLQ

While Auth0 is an Authentication (AuthN) solution (verify your identities and add attributes to them) - Permit.io is Permissions or Authorization (AuthZ) solution (who can do what) - and enforces the actual policy within your app (for every request). AuthZ is a needed and complimentary component on top of AuthN

You pass the JWTs from your AuthN solution to permit's permit.check() function.

Read more: - https://www.permit.io/blog/what-is-authorization - https://docs.permit.io/tutorials/quickstart#check-for-permis...

Hi! We provide an on-prem version (as part of our enterprise tier); but better yet the SaaS solution itself is hybrid- meaning we provide a microservice for authorization for you (aka the PDP), and it answers all the queries locally from memory cache - which is great for security, but also latency (sub 10ms as a sidecar), and availability.

Updates are done through OPAL (https://opal.ac) - which has a a zero trust architecture (it sends instructions on how to get the data instead of the data itself) based on topics scoped with security tokens.

You can read all about it here: - https://docs.permit.io/concepts/control-plane-and-data-plane...

- https://docs.permit.io/security/connectivity

Glad you like it! Let us know if you need any help to get started. We are very responsive on Slack :) https://bit.ly/permit-slack

Seems like you're trolling with your user you created less than 10 minutes ago... :D But here's a serious honest answer: OPA is the fundamental policy engine used by this tool to write and enforce policies. It does not, however, offer the ability to abstract, control, and manage permissions through a UI. Rego code isn’t easy to write, and managing this with OPA only still leaves 100% of the work on the dev side. The idea here is to allow your end users (Which, a lot of the time, are not technical at all) to manage permissions without having to write code, and without the devs having to build a UI that allows them to do so.