> For the complete documentation index, see [llms.txt](https://docs.arnica.io/arnica-documentation/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.arnica.io/arnica-documentation/security/role-based-access-control-rbac.md). # Role Based Access Control (RBAC) ## Summary Arnica's Role Based Access Control (RBAC) allows each user to be assigned a designated role within the Arnica solution. When authenticated, the user will be provided access to certain pages and functionality based on their role. These roles can be defined within Arnica or through SSO. ## Arnica managed and SSO managed RBAC Arnica's RBAC has two primary configurations: Arnica Managed and SSO Managed roles. Arnica admins can switch between these two configurations within the Users and Roles page. {% hint style="warning" %} When switching between "Arnica" and "SSO" management configurations, you must save the configuration before the change will take effect. {% endhint %} ### Arnica Managed RBAC When RBAC management is set to "Arnica", all roles must be managed directly within the Arnica solution. A users role can be updated by clicking the "Edit" icon in table beside the "Delete" icon. When a user's role is changed in the Arnica Users and Roles table, the changes take immediate effect. ### SSO Managed RBAC Arnica offers the ability to set roles through the use of SSO groups. When SSO management is set to "SSO", a new configuration window will appear that allows you to define your SSO user groups and map each group to the appropriate Arnica role.\ \ Once configured, the role of each user is assessed each time they interact with the Arnica solution. If a user is removed from an SSO group, their permissions will change the next time they load a page within Arnica.

Arnica's SSO Roles Configuration Panel

## Configuring SSO Roles in Arnica The SSO Groups Roles Map includes a table with 3 required variables: Name, Regex, and Role. * **Name -** Used to assign a name to each group's mapping policy. * **Regex -** A regex is used to define which role passed by your SSO provider should apply to this policy. * **Role** - The role that the user should be assigned when they are a member the group defined in the {% hint style="info" %} Users can inherit multiple roles. If a user is a member of more than one group configured they will be given multiple Arnica roles, visible as icons in the user table. {% endhint %} ## Arnica Roles Definitions * **Owner** — Full access to all pages, reports, and functionality. Same platform permissions as Admin, plus tenant ownership: rename the organization and delete the tenant. The Owner role is not assigned via the Users & Roles role picker; the org owner's role cannot be changed through normal role edits. * **Admin** — Full access to all pages, reports, and functionality, with the same admin capabilities as Owner (including inviting users, removing users, changing roles, SSO role mapping, policies, integrations, billing, API keys, and AI configuration). Admins cannot rename or delete the tenant. * **Security Reviewer** — Edit access to risk pages and org-wide Inventory (including Git Summary and Products). Can change finding status and dismiss findings directly (not subject to dismissal review). Cannot access Admin pages such as Users & Roles, Policies, Integrations, Plan/billing, or API keys. * **Maintainer-Product** — Product-scoped edit access to risk pages, Products, and Repositories within assigned products. Can edit product makeup and repo-level settings in scope. Can change finding status; if **Require Review for Dismissals** is enabled, dismissals require review. Cannot create products, cannot access org-wide Inventory Summary/Identities/Git Summary, and cannot access Admin pages. * **Collaborator** — Edit access to org-wide risk pages and SBOM. Can change finding status; dismissals may require review when that policy is enabled. No Inventory (beyond SBOM), Git Summary, or Admin pages. * **Collaborator-Product** — Same as Collaborator, limited to assigned products. * **Read-Only** — Read-only access to org-wide risk pages and SBOM. Cannot change finding status or review dismissals. * **Read-Only-Product** — Same as Read-Only, limited to assigned products. {% hint style="info" %} Ownership transfer is an Arnica support / internal-admin action. Tenant Admins cannot transfer ownership in-product. {% endhint %} ## Role assignment guidance The following role patterns are commonly used: * **Application security architects**: `Security Reviewer` * **Team lead / project manager for a product**: `Maintainer-Product` * **Developers**: `Read-Only` as a baseline * **SBOM-only stakeholders**: `Read-Only-Product` {% hint style="info" %} Use `Read-Only` (not `Read-Only-Product`) for users who need full visibility into Secrets and Code Risk pages. Product membership (for example, who owns a product in Inventory) is separate from Arnica RBAC roles — there is no Arnica role named "Product Owner." {% endhint %} ## Operational notes ### Why restricted users may still see unavailable menu items In some role configurations, UI navigation can still display pages a user cannot access. In that case, role permissions remain authoritative and access is limited to permitted sections. ## Can I manage Roles in Arnica and access through SSO? Yes. Arnica's authentication and role assignment features are configured separately. It is possible to set up SSO login and have user roles configured within Arnica. ## SSO RBAC Feature Dependencies Arnica's SSO managed roles rely on attributes passed during the SSO authentication process, so It is not possible to map SSO based roles without configuring SSO authentication.\ \ To take advantage of this feature, ensure that you have properly integrated Arnica with your SSO solution and that you have included the "user. Groups" argument in the SSO authentication response. More detail on this configuration can be found in the [Okta Integration page.](/arnica-documentation/security/sso-integration/okta-integration.md)