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).
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.
I guess it seems somewhat mixed as Auth0 also has some elements of RBAC but agree that it is not meant to lock down individual items - just api level. However, I think your approach of separating this out is a good idea for your product as many organizations will have already chosen an identity provider (often AzureAD). In any case, best of luck and I will check it out!
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.
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.
Hi there! I appreciate the concern - But note that Permit elements allow you to delegate access control to any one of your team members, end users, or customers - as it uses a simple no-code UI to do that, It could allow your security team easier access to overview the entire process, and thanks to Permit.io building on policy as code you always have full control of the generated flow via Git.
Thank you for the congrats and the good question.
First of all building on your own, is a valid option- each application is a snowflake you should find what's best for you.
That said, just like with cryptography, and authentication, it can be risky to roll your own.
If you decide to roll on your own with OPA - I'd also recommend sticking to best practices [Gitops is just one] (checkout this talk I gave on OWASP- https://youtu.be/1_Iz0tRQCH4) , and also finding a solution for managing the authorization layer (e.g. https://opal.ac)
To this point specifically- "Do you offer a way of auditing and tracking who made changes to permissions" - Yes, check out Permit's audit-log interface
In general on top of the interfaces you get with OSS like OPA and OPAL, there are a lot more interfaces to build (e.g. audit logs, user mgmt, policy editing, approval flows, etc.) and none of them are unique to any application.
