I'm seeing unexpected behavior on RBAC checks in my production environment and hope someone can point out if I'm thinking about this the wrong way. The screenshots show (1) a resource level role group#groupContributor which has some actions enabled including list-group-process. (2) A user who has the groupContributor role for a specific group instance. (3) A denied permission check by that user on that same group instance for the list-group-processes action.

Hi @Jack Muller, I'm an AI assistant for Permit.io. I'll analyze available sources and get back to you shortly.

Hey, thanks for reaching out ! It seems our team is a little busy right now, a human will be with you within the next hour or so. In the meantime, can I help you ?

Based on the documentation, your setup appears correct. Resource roles (like

group#groupContributor

) are designed to grant permissions on specific resource instances (1) (2) . When a user is assigned a resource role for a particular instance, they should have the permissions defined for that role on that instance. Here's what the documentation shows about resource role configuration:

resource "permitio_role" "Sender" {  
 key = "Sender"  
 name = "Sender"  
 resource = permitio_resource.Transaction.key  
 permissions = ["list"]  
 depends_on = [permitio_resource.Transaction]  
}

(1) And for resource role assignment:

await permit.api.roleAssignments.assign({  
 role: "Sender",  
 tenant,  
 resource_instance: `Transaction:${transaction.id}`,  
 user,  
}) ;

(2) Since you're experiencing unexpected denials, let me help you troubleshoot. Could you please provide: 1. Which Workspace / Project / Env you are using 2. What calls you are performing (as SDK code or CURL) - specifically the exact check call for the

list-group-processes

action 3. Which PDP version you are running 4. Relevant logs from your PDP showing the permission check evaluation This information will help our engineers investigate why the permission check is being denied despite the role assignment appearing correct.

The workspace is FabuBlox, Project is default, Env is production. I'm using the permit sdk to call the check method. The args passed to the check method are correctly showed in the pdp decision screenshot

Hi @Jack Muller, Thanks for the detailed report. One of us will get back to you, since it’s the weekend, that’ll most likely be at the beginning of the week.

Thanks @Eli Moshkovich that’s great. I’ll be looking into this more on Monday

Hey @Jack Muller the things you refer to as rbac and rebac are only the “debug information”, the overall answer for the last screenshot you attached should be true ( it’s an “or” operation rbac, abac, rebac ) The answer is made by rebac - every resource role / derivations roles rbac - top level roles only abac - user sets and/or resourcesets

Hi @Omer Zuarets thanks I do see it’s an OR across them. The focus of my question is the user is not being allowed despite their valid role on the group instance

Hey @Jack Muller, will make sure @Omer Zuarets see it and will circle back

Hey @Jack Muller I’ll send you a PM shortly as the explanation includes your policy description