Show HN: Permit Elements- UIs to let your customers manage their own damn RBAC(youtube.com)
youtube.com
Show HN: Permit Elements- UIs to let your customers manage their own damn RBAC
https://www.youtube.com/watch?v=2d4TwyvBh8M
22 comments
Guys, you can't do promotional upvoting and commenting on HN. This is in both the site guidelines and the FAQ—that's how important it is:
https://news.ycombinator.com/newsguidelines.html
https://news.ycombinator.com/newsfaq.html
HN users are extremely vigilant about it and can usually figure out what's going, as they did here, and then they flag the posts and complain to us and use unkind words like 'spam'.
https://news.ycombinator.com/newsguidelines.html
https://news.ycombinator.com/newsfaq.html
HN users are extremely vigilant about it and can usually figure out what's going, as they did here, and then they flag the posts and complain to us and use unkind words like 'spam'.
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.
I don't know. This seems to be something I’d get a slap on the hand from our security team. No chance ever they give away the power they have for control who have permission. Just me??
I think this should not be a problem with the proper compliance certifications (SOC 2, PCI, etc.). Similar logic applies to Auth0 and even using cloud computing, for that matter.
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.
I like where this is headed.
A lot of application frameworks have some kind of a security policy engine, but all of these invariably are inadequate - because modern policy management is about interfacing outside of systems, and that they don't do.
Exactly in the same way that load balancing should not be a part of an application framework, neither should authorization.
A coherent, formalized, well manageable policy engine can go a great deal for practical organization security
A lot of application frameworks have some kind of a security policy engine, but all of these invariably are inadequate - because modern policy management is about interfacing outside of systems, and that they don't do.
Exactly in the same way that load balancing should not be a part of an application framework, neither should authorization.
A coherent, formalized, well manageable policy engine can go a great deal for practical organization security
Is this kind of like Auth0 but with more common features built in, or is something like auth0, AzureAD still needed in order to issue jwts?
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...
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...
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!
How is this different from what I can get from OPA?
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.
Can you self host this? Feels dangerous to check an external service for RBAC.
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
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
[deleted]
diversion(1)
avihu(1)
tamir2020(1)
We adopted OPA, created OPAL.ac (open-source), and Permit.io on top - so no developer would have to build permissions again.
To truly solve this problem end-to-end we’re releasing Permit-Elements (https://permit.io/elements) - embeddable UIs providing the interfaces you need so your end-customers can control access-control (e.g. user-management, audit-logs, approval flows, permission requests, api-key management, …)
Check out the full tutorial: https://youtu.be/xGYdDF65lkQ
The solution highlights: - Authorization for Authorization (who can control who controls permissions) - Security (auditing, real-time decision making and meeting industry standards) - An easy integration (generate and embed a JS snippet)
There’s a lot more to do, we’d love your feedback on Permit in general, this feature, and others. Chat with us on Slack (https://bit.ly/permit-slack)
Thanks, Or Weis