Hi guys, I'm trying <Permit.io> and I'm struggling...
# general
a
Hi guys, I'm trying Permit.io and I'm struggling with giving fine-grained permissions for specific users. What I want to do is the following:
Copy code
Tenant A:
  * User A
    * Role: Viewer
    * Additional/override permissions: Create document
  * User B
    * Role: Editor
...
Is this possible in the current system? I'm getting really confused with the "instance", "policy" and "resource" terminology
d
Hi Amir, yes this is possible. What you're describing requires combining RBAC (Role-Based Access Control) with additional instance-level permissions. Lets see what @Ask Inkeep suggests
a
Thanks for tagging me @david. I'll look through relevant sources and get back to you shortly.
Yes, what you're describing is possible. You want to give User A the "Viewer" role but also grant them an additional "Create document" permission that Viewers don't normally have. (1) ​*Understanding the terminology:*​ (2) (1) ​*Resources*​ are the objects you want to protect (like "document") . (1) ​*Actions*​ define operations that can be performed on resources (like "create", "read", "update") . ​*Roles*​ are collections of permissions that can be assigned to users. ​*Instance*​ refers to a specific resource instance with its own permissions - this is key for fine-grained control. (3) ​*How to implement your scenario:*​ You can use ​*instance-level role assignments*​ to override or extend base role permissions. When syncing users with Permit, you can assign roles at the instance level using `role_assignments`:
Copy code
await permit.api.users.sync({
  key: 'user_a',
  email: '<mailto:usera@example.com|usera@example.com>',
  role_assignments: [
    { role: 'viewer', tenant: 'tenant_a' },
    { role: 'creator', resource_instance: 'document_123' }
  ]
}) ;
This approach allows User A to have the "Viewer" role at the tenant level while having additional "creator" per
To learn more, see the sources I considered: [[1] Policy Basics](https://docs.permit.io/how-to/build-policies/policy-basics) [[2] Concepts / Glossary](https://docs.permit.io/overview/glossary) [[3] Implementing Fine-Grained Nuxt Authorization](https://www.permit.io/blog/implementing-fine-grained-nuxt-authorization)
a
Thanks for the quick response 😄 @Ask Inkeep is there a way to achieve this granularity in the UI (for a code-free adjustments)?
a
Thanks for tagging me @Amir Tugendhaft. I'll look through relevant sources and get back to you shortly.
* Yes, you can manage users and their role assignments through the Permit.io UI without writing code. (1) The ​*User Management*​ interface allows you to: • Create new users • Update existing users • Delete users • Assign roles to each user • Assign users to tenants You can access this through the User Management web interface at app.permit.io/user-management. For your specific scenario (User A with Viewer role + additional Create document permission) , you would: 1. Navigate to User Management 2. Select User A within Tenant A 3. Assign the "Viewer" role at the tenant level 4. For the additional permission, you'd need to either: • Create a custom role that combines Viewer permissions + Create document • Or use the API for instance-level role assignments (as the UI primarily handles tenant-level role assignments) The UI is designed for managing tenant-level role assignments. For more granular instance-level permissions (like giving User A create permissions on specific documents) , the SDK approach I mentioned earlier is the recommended method. (2) Would you like guidance on creating a custom role in the UI that includes both Viewer and Create p
To learn more, see the sources I considered: [[1] Policy Basics](https://docs.permit.io/how-to/build-policies/policy-basics) [[2] Implementing Fine-Grained Nuxt Authorization](https://www.permit.io/blog/implementing-fine-grained-nuxt-authorization)
a
@david so the information from the AI agent is useful, and I still have 1 piece that is not clear to me. Isn't it possible to just assign a specific permission, from the permissions list I've created, to the user? Doesn't it create an additional overhead to create a custom role?
d
Permissions cannot be assigned directly to individual users, they must be grouped into roles first. While it may be additional overhead - the role-based approach provides several benefits: • Reusability: If another user needs the same permission combination later, the role already exists • Maintainability: Changes to permission sets can be made at the role level rather than per-user • Scalability: As your system grows, role-based management becomes more efficient than individual permission assignments
a
I see. So in that case - what are use cases you see for creating the custom/instance roles? I'm trying to figure if my product would require FGA or we can make do with regular RBAC
d
Without knowing much about what youre working with, it depends on how granular you would like to get. Do users in your product need to share or collaborate on specific resources (documents, records, accounts) with different people having different permissions on those specific items? If yes, you likely need FGA/ReBAC. If users simply need consistent permissions across all resources of a type, RBAC may suffice. We have good demos that explain use-cases and which configurations work best. I recommend taking a look https://docs.permit.io/category/learn-by-example
a
Will do, thanks 😄