Show HN: Permit Elements- UIs to let your customers manage their own damn RBAC

https://www.youtube.com/watch?v=2d4TwyvBh8M

by orweis • 3 years ago

60 13 3 years ago

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

odedbend• 3 years ago

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??

orweis5• 3 years ago

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• 3 years ago

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.

michaelbd• 3 years ago

How is this different from what I can get from OPA?

orweis5• 3 years ago

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.

YouWhy• 3 years ago

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• 3 years ago

Can you self host this? Feels dangerous to check an external service for RBAC.

orweis5• 3 years ago

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

osigurdson2• 3 years ago

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?

orweis5• 3 years ago

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.

osigurdson2• 3 years ago

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!

dang• 3 years ago

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

orweis5• 3 years ago

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.

Show HN: Permit Elements- UIs to let your customers manage their own damn RBAC

Related Stories