HN Explorer

Show HN: Permit Elements- UIs to let your customers manage their own damn RBAC (youtube.com)

60 points by orweis ↗ HN
Hi HN! Co-Founder of Permit.io here, I’ve built access-control to my products, thousands of times throughout my career - and at no point did I want to.

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

22 comments

[ 2.9 ms ] story [ 50.7 ms ] thread
odedbend
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??
orweis
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.
varunsharma07
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.
[deleted]
(comment deleted)
michaelbd
How is this different from what I can get from OPA?
orweis
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.
[dead] On
[flagged]
YouWhy
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

pantojax45
Can you self host this? Feels dangerous to check an external service for RBAC.
orweis
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

osigurdson
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?
orweis
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...

osigurdson
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!
[dead] tamir2020
[flagged]
orweis
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

dang
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'.

orweis
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.