# Explicitly assigning role to principal
Cerbos intentionally doesn't assign roles to principals inside its perimeter; roles are expected to arrive with each request from outside Cerbos, and maintainers say principal-to-role mappings are out of Cerbos' remit. If you need role-like grouping inside your policies, use derived roles driven by exportConstants, e.g. an exportConstants list of admins plus a derived role matching request.principal.attr against it, per the dynamic policies best practices in the Cerbos docs. Bottom line: Cerbos solves authZ, identity and role storage live in your external system.
## Context from the issue
gh:cerbos/cerbos#2567: Issue cerbos/cerbos#2567 (closed, 6 comments): ### Is there an existing issue for this? - [x] I have searched the existing issues ### Feature description Hello! Currently Cerbos allows to - assign `permissions` to `principal` - assign `permissions` to `role` It seems that there is a lack of a piece of puzzle - ability to explicitly assign `role` to the `group of principals`. Imagine RBAC or PBAC where users got their `permissions` depending on context and general predefined rules, but what if we want to give an admin `role` for `selected principals`? And then, auditor role for another group of them.