https://play.cerbos.dev/p/TRVALlguLg62a94ec4vIA7rEqVILoIha The user role can view:public， then I create a test role extends the user role, the result is: the user role can view:public, but the test role's view:public is denny. I think the test role should extends the user roles's 'view:public' policy, but it does not, is it a bug? or am I using it wrong?

You need to add a rule for the

test

role.

- actions: ['view:public']
      effect: EFFECT_ALLOW
      derivedRoles:
        - test
# add a condition if necessary

The user role EFFECT_ALLOW the 'view:public' action. I have set the test role's parentRoles: user. I wonder if the test inherits the user's action?

Sorry, I’ve just noticed you’re passing the

test

role in the request.

Yes, the user1 request to the Resource1, meet the conditions of the user role and the test role

You passed

test

role in the request. Cerbos assumes it is a parent role and can’t find it.

Let me think about it for a second, and I still feel like role inheritance isn't working. I'm going to eat now, see you later. Thank you very much!

No worries. I’ll be glad to help

We also got confused on the role inheritance in the same way @Dennis (Cerbos) @Alex Olivier (Cerbos)

Thanks for flagging - we need to do a better job of documentation and examples on this then. @seala va we run free policy workshops where we can go into your use case in detail and assist in writing your first policies. If this will be helpful, you can book some time.

I want to build a GUI to manage authorization, but I have no specific idea for that. Just test some scenes.

It looks like you want Cerbos to infer a ‘user’ role from the

test

role and attributes. Cerbos works in a different way: the request contains the parent roles (

user

in your case), the attributes and the cerbos derive a new role “test”.

@Dennis (Cerbos) Sorry, my previous expression was a bit confusing. I read the cerbos documentation again and sorted out my thoughts. What I mainly want to express should be: in cerbos, how to declare the inheritance relationship of rbac roles. For details, please see the readme and policies in the playground. https://play.cerbos.dev/p/BOjBdsZv7Flz62a9abc4NNkxN1Rm9LSc

The most straightforward solution would be to have separate rules for all roles and then you’d pass inherited roles in the request, so for a member you would pass

roles: ["member", "guest"]

. For editor `roles: ["editor", "member", "guest"]`` etc.

Hi Seala. Cerbos is stateless and does not store your roles and their relationships. We leave that to the identity providers (IdP). When writing policies, you need to be explicit and specify all the roles that can/cannot do a certain action. Similarly, when making a request, you have to resolve all the role inheritance relationships in your application and provide Cerbos with that list.

Thanks @Dennis (Cerbos) and @Charith (Cerbos) Ok, I see. Is there a good identity providers framework written in nodejs language to recommend?

Here’s an example with express and Auth0 https://github.com/cerbos/express-auth0-cerbos

@seala va we are using Cerbos with Auth0 (our tech stack is full-stack JS reactjs and nodejs) and I can totally recommend it

OK, Thanks!

The most straightforward solution would be to have separate rules for all roles and then you’d pass inherited roles in the request, so for a member you would pass

roles: ["member", "guest"]

. For editor `roles: ["editor", "member", "guest"]`` etc.

I think this is were we somehow got confused as well and the name "derived role" didn't help either. I think there is a sort of inheritance but only at the 1st level. It does't go deeper than that. For instance, we have a case where we have internal and external users for our application. and external users can have 2 roles: "data provider" or "agency". Then we can make deal with different agencies which can have different permissions (an easy example is allowed or deny specific sections of the application or to do some sort of action on a resources). We were thinking of starting from external users, give some default permissions (common for both data provider and agency roles), then add more (or overriding if necessary) based on the different needs of data provider and agency. After that, the plan was to keep going. For example for agencies, we wanted to derived a further role from agency role, for example agencyA, and again, adding or overriding based on requirements. So on and so forth. INTERNAL USERS • DIRECTOR • SALES • etc. EXTERNAL USERS • AGENCY ◦ AGENCY A ◦ AGENCY B ◦ etc. • DATA PROVIDER ◦ DATA PROVIDER A ◦ DATA PROVIDER B ◦ etc.

Does cerbos plans to support role inheritance in the future?I think it's still useful in some scenarios.

Well, role inheritance is quite complicated. It needs really tight integration with IdPs and the biggest problem is making sure the role relationship data is always in sync (if it is stale, Cerbos could make wrong access decisions). Duplicating data between the IdP and Cerbos is not ideal and, on the technical side, there's also the massive problem of having to deal with multiple different IdPs including custom ones created by our users. The only way to reliably support role inheritance is if we build IdP functionality into Cerbos. But, that makes Cerbos very complicated and quite invasive to implement. We also feel that identity management is a solved problem so there's no point in reinventing that wheel. So, at least for the time being, we don't have plans to support role-inheritance natively within Cerbos.

Hey, @Charith (Cerbos) this is very interesting to me. I definitely agree with you that IdP is a solved problem that doesn't need to be solved again, but I am very curious to understand exactly the relation of IdPs and Cerbos for role inheritance that you were describing. In my head, with Cerbos, you don't need to use IdPs for roles much at all. I think you either need only a basic role (for instance user and admin) and some other information to give you more user context (metadata) or you can be a little more specific and assign a high-level role (in our case could be for example Director, Agency, etc.) and from there you can do there rest in Cerbos. Cerbos engine needs to understand and store these relationships. I know this is a massive oversimplification, and I don't know all the details, but I can really see how this could be a killer feature for Cerbos, and it would save lots of time and mistakes for people. At least I think, I might be 100% wrong here. I also do understand that by design you probably don't want to make it too easy in this case, otherwise, it wouldn't make your product sellable using a UI interface which I am sure will eliminate mistakes and repetitive work.

Hi Luca. If your role relationships are static, then absolutely, I agree it would be nice to be able to define them with Cerbos. Of course, that's still not without issues like how to model relationships (the unusual ones, at least) and resolving conflicts with multiple inheritance etc. What we are mostly worried about are the dynamic environments where these relationships change much more quickly. Those cases would be difficult to handle without integrating with IdPs. It's hard to build something that would cater to everybody. That's why, even if it's a little inconvenient, we are currently relying on our users to resolve these relationships on their end. Your use case is quite interesting. We'll definitely think about that a bit more and what we might be able to do to make your life easier.

This is my usage, I don't know if this is correct: https://github.com/issuebox/cerbos-discuss/blob/main/role-inherit.md

There is a 3rd way to do this via creating a “common_roles” set of derived roles. I’ve created this playground instance to demonstrate https://play.cerbos.dev/p/Kwmkyf1kk862ac54576tH9XNch04d7Na

What the guest can do, the member can do too, I think it shouldn't be: `member'`s parentRoles is [

guest

], but why it is opposite。 In the comments below is what I think it should be:

the way to think of these is that if the IdP role is in the a

parentRoles

list, the user is given an extra role of the value

name

. In my example, the user will be given the

guest

role if the IdP role is one of

admin, editor, member, guest

got it, thanks!

Thank you @Charith (Cerbos) I do get it, and you are 100% right. Cerbos is an amazing product, and you should be very proud of what you have done so far. Having said that, anything can improve in life, especially products. I am sure you will improve it a lot. I hope you will be very successful because you deserve it! 🤘

Thank you @Luca Carangella,That's very kind. We really do want to make the product delightful to use. So, please keep bringing up the issues and pain points (no mater how small) that you're facing and we'll do our best to help you out. We are going to be doing a lot of thinking about this particular issue as well -- so it's not the end, yet 🙂

Very interesting! @Mykola Belgovskyi ☝️ what do you think?

This is a good tool which can solve our problems, but I'm slightly confused about when you want to crate new scoped policies schema (for new office for example) vs adding derived roles into existing policies. 4 lvl limitation for scopes seems weird.

Variables and derived roles imports are not inherited between policies. Explicitly import any derived roles and re-define any variables in each policy that requires them.

As I understand scoped policies can't inherit main ones. This will require me to copy-paste all permission structure for new office even if I need to change few small things.

Hi @Mykola Belgovskyi scoped polices do inherit the access rules from parents so you don't have to re-define them again. You only need to define the overrides. If there's no rule defined for a particular action in the agency policy, Cerbos will check the parent policies.

The Cerbos engine could process up to four policies to arrive at the final decision:

I thought this means that if you will use your scopes fully on each step (not just

a.b.c.d.e

scope without having

a.b

scope) means you can't practically go deeper than 4. Or were you mentioning only about current example? If that is so it seems a good option to use this feature.

Yeah, that's just for that particular example because the longest scope had 3 segments. There's no built-in limitation for scopes in Cerbos 🙂