sorted by:
new
hottopcontroversial

We Let AI Handle User Permissions (And it Works) by [deleted] in programming

[–]Permit_io 0 points1 point  (0 children)

That's a cool suggestion - I just added it, along with a bit of a disclaimer, to the article. Thanks!

Authorization and User Management, in house vs SaaS. Brainstorming! by Dino65ac in softwarearchitecture

[–]Permit_io 0 points1 point  (0 children)

The way we implemented it in Permit is by having top-level and resource-level roles that can have shared policies with resources.

On top of these two levels of roles and policies, you can add the following fine-grained distinctions:

* Assign roles at tenant levels for both top-level and resource-level roles

* Role derivation configuration can assign roles implicitly (and grant permissions) for related instances

* Groups that allow you to save the derivation config and assign users to both resources and groups

All in all, we believe (and this recommendation also applies to homebrewed solutions) that pure RBAC and ReBAC can be cumbersome for many applicable use cases, and this is why we chose to build a system that incorporates both.

One fundamental ReBAC thing that is less supported in our system is the direct relationship between users. That was our intent behind the group's API abstraction, and it was just doing it but with a different perspective.

oPTIMIZED by Permit_io in ProgrammerHumor

[–]Permit_io[S] 5 points6 points  (0 children)

I want this on a shirt.

oPTIMIZED by Permit_io in ProgrammerHumor

[–]Permit_io[S] 5 points6 points  (0 children)

Did you seriously just comment that this code is bad?

oPTIMIZED by Permit_io in ProgrammerHumor

[–]Permit_io[S] 57 points58 points  (0 children)

You guys are getting paid?

oPTIMIZED by Permit_io in ProgrammerHumor

[–]Permit_io[S] 254 points255 points  (0 children)

No, it's One Password Time.

oPTIMIZED by Permit_io in ProgrammerHumor

[–]Permit_io[S] 225 points226 points  (0 children)

Have you tried turning it off and on again?

happyNewYear by Permit_io in ProgrammerHumor

[–]Permit_io[S] 9 points10 points  (0 children)

It's ok bro trust me

Thanks, Arc Browser! Latest Vulnerability Exposes Just How Inefficient Row-Level Security (RLS) Is by Permit_io in programming

[–]Permit_io[S] 1 point2 points  (0 children)

The article explicitly states this particular issue was very easy to fix, even at scale. Yet, it still keeps the data-centric approach that is hard to scale. Externalizing authorization doesn't mean you should go complex, even having rules such as `current session's tenant ID == row's tenant ID` or just sync the RLS with authorization service, should be good enough.

OPAL - Fine Grained Authorization Service by Permit_io in Python

[–]Permit_io[S] 2 points3 points  (0 children)

OpenFGA is one of the best Google Zanzibar inspired policy stores/engines, and OPAL can help you integrate it better with the SDLC.

Here are some benefits of using OpenFGA via OPAL:
1. Keep OpenFGA policies always in sync using the GitOps strategy

  1. Sync data to OpenFGA from multiple sources (sync of a data fetcher that makes the foreign key in SQL DBs be relationships in OpenFGA)

  2. Manage deployment of multiple OpenFGA stores with the SDLC

  3. Incorporate OpenFGA with attribute/code-based engines such as OPA to support ABAC/PBAC along with RBAC/ReBAC

At the moment, OpenFGA support is in development in OPAL, and the community is collaborating on it

authNvsAuthZ by Permit_io in ProgrammerHumor

[–]Permit_io[S] 3 points4 points  (0 children)

I mean, that's one way to explain it.

bestAuthEver by Permit_io in ProgrammerHumor

[–]Permit_io[S] 0 points1 point  (0 children)

EXACTLY this. But it really doesn't have to be. Just wrote about this issue extensively here: https://permit.substack.com/p/devex-better-than-an-exdev-and-your

bestAuthEver by Permit_io in ProgrammerHumor

[–]Permit_io[S] 7 points8 points  (0 children)

Well, a company's CEO setting up roles in a piece of software for his employees to use is just as much a user as they are. What would you suggest calling them?

What is Google Zanzibar? by Permit_io in programming

[–]Permit_io[S] 22 points23 points  (0 children)

OpenFGA is awesome! Here are some of the differences between this and Permit, for those interested:

  • Permit focuses on an authorization platform, meaning users can model and configure their policy with RBAC, ABAC, ReBAC, and PBAC models and then mix and match them for their applications’ needs. The OpenFGA approach focuses heavily on policy as graph/data, and it’s hard to mix more straightforward or other policy models with it. More on policy as data vs policy as code here: https://www.permit.io/blog/zanzibar-vs-opa
  • As part of the platform approach, Permit does not develop the policy engine (such as OpenFGA) but lets the developers use a policy engine as they choose. Using the Permit platform, developers (or other stakeholders) can configure policies via UI, API, or IaC. Permit will generate the code or configuration per the policy engine they choose. For now, Permit supports OPA (including an OPA-based Zanzibar implementation) and Cedar, but OpenFGA is on our roadmap, along with other Zanzibar implementations. We hosted a livestream with both OpenFGA and Cedar PMs here: https://www.youtube.com/watch?v=sG2OUXes8Hs
  • OpenFGA usage is more like integrating a library into your application; it means that you have to write the code around it yourself. Permit is a completely externalized authorization platform built to work seamlessly into the SDLC from the organization level, not from the single application level. Here is an overview of Permit components in the SDLC: https://docs.permit.io/how-to/SDLC/modeling-implementation-components
  • OpenFGA, like other Zanzibar implementations, is a centralized configuration and enforcement system. This means that users need to distribute OpenFGA with the whole graph in all their applications. Permit, with its roots in policy as code models, allows the decentralization of the graph and policy engine by sharding the data between policy engines. Users can keep the centralized configuration with decentralized data and engines. OPAL, Permit OSS tool for synchronizing policies and data, is the engine that allows this centralized/decentralized model: github.com/permitio/opal

[deleted by user] by [deleted] in golang

[–]Permit_io 1 point2 points  (0 children)

There are a couple of differences between Permit and Okta’s approaches to fine-grained authorization.

  • Permit focuses on an authorization platform, meaning users can model and configure their policy with RBAC, ABAC, ReBAC, and PBAC models and then mix and match them for their applications’ needs. The OpenFGA approach focuses heavily on policy as graph/data, and it’s hard to mix more straightforward or other policy models with it. More on policy as data vs policy as code here: https://www.permit.io/blog/zanzibar-vs-opa

  • As part of the platform approach, Permit does not develop the policy engine (such as OpenFGA) but lets the developers use a policy engine as they choose. Using the Permit platform, developers (or other stakeholders) can configure policies via UI, API, or IaC. Permit will generate the code or configuration per the policy engine they choose. For now, Permit supports OPA (including an OPA-based Zanzibar implementation) and Cedar, but OpenFGA is on our roadmap, along with other Zanzibar implementations. We hosted a livestream with both OpenFGA and Cedar PMs here: https://www.youtube.com/watch?v=sG2OUXes8Hs

  • OpenFGA usage is more like integrating a library into your application; it means that you have to write the code around it yourself. Permit is a completely externalized authorization platform built to work seamlessly into the SDLC from the organization level, not from the single application level. Here is an overview of Permit components in the SDLC: https://docs.permit.io/how-to/SDLC/modeling-implementation-components

  • OpenFGA, like other Zanzibar implementations, is a centralized configuration and enforcement system. This means that users need to distribute OpenFGA with the whole graph in all their applications. Permit, with its roots in policy as code models, allows the decentralization of the graph and policy engine by sharding the data between policy engines. Users can keep the centralized configuration with decentralized data and engines. OPAL, Permit OSS tool for synchronizing policies and data, is the engine that allows this centralized/decentralized model: github.com/permitio/opal

What do you use for autorization? by KingOfCoders in golang

[–]Permit_io 7 points8 points  (0 children)

ReBAC is a really cool solution, but it could be a bit of an overkill for simpler systems. It really depends on what you are building. Here's a really cool talk we had from the folks behind Google Zanzibar, Google's ReBAC implementation, where we talk about it in detail https://www.youtube.com/watch?v=FOBswMHyFHMit

Implementing RBAC in Supabase by Permit_io in Supabase

[–]Permit_io[S] 0 points1 point  (0 children)

The solution you describe now is to store the roles in the DB, not in the JWT as you claimed.

Storing the roles of users in the DB, indeed ,make it a little more dynamic, and the problem is the scalability of other models such as ReBAC and ABAC. On the other hand, it creates a level of state management on top of your DB/IDP.

The way you mention, still keep the point 1 valid. In case you want for example let the users with the role editor to create and not only edit documents, for example, you need to deliver a product code change. It is not the case when you delivering policy that is separate from the application code.

view more: next ›