Role scope and permission inheritance in Nexus IQ
Sonatype Nexus IQ uses role-based access control (RBAC) to manage access to applications within a SHIP-HATS project. Roles define what actions users can perform, such as viewing reports, evaluating applications, or administering policies.
Assignment levels
You can assign roles for users and user groups at the following levels:
Project level
Roles assigned at the project level apply to all Nexus IQ applications within the selected SHIP-HATS project.
This includes:
- All existing Nexus IQ applications in the SHIP-HATS project
- All future Nexus IQ applications created in the SHIP-HATS project
Use project-level assignment when:
- Users need access to multiple Nexus IQ applications
- Ensuring consistent access across applications
Application level
Roles assigned at the application level apply only to the selected Nexus IQ application. Application-level assignment is useful when users require access to specific applications only.
Use application-level assignment when:
- Users need access to specific applications only
- Restricting access to sensitive applications
- Providing limited or temporary access
- Granting different roles for different applications
Permission inheritance
By default, roles assigned at the project level are inherited by all applications in the project.
Project-level roles automatically apply to all applications in the project.
Application-level roles apply only to the selected application.
Roles are cumulative. If a user has roles at both levels, permissions are combined.
Application-level roles do not reduce or remove inherited project-level permissions.
Role assignment scenarios
The following scenarios illustrate how access behaves under different role assignment combinations.
| Scenario | Project-level role | Application-level role | Access to Application A | Access to Application B | Explanation |
|---|---|---|---|---|---|
| 1 | None | None | ❌ No access | ❌ No access | No role assigned at any level. |
| 2 | Developer | None | ✅ Developer | ✅ Developer | Project-level role applies to all applications. |
| 3 | None | Application Evaluator (App A) | ✅ Application Evaluator | ❌ No access | Access limited to App A only. |
| 4 | Developer | Application Evaluator (App A) | ✅ Developer + Application Evaluator | ✅ Developer | Roles are cumulative. App-level role adds permissions for App A. |
| 5 | Developer | Application Evaluator (App B) | ✅ Developer | ✅ Developer + Application Evaluator | App-level role applies only to App B. |
| 6 | Developer | None (App-level removed) | ✅ Developer | ✅ Developer | Removing app-level role does not remove project-level role. |
| 7 | None | Application Evaluator (App A & App B) | ✅ Application Evaluator | ✅ Application Evaluator | Multiple app-level assignments without project-level role. |
Assign roles to user groups
The same Permission inheritance rules and Role assignment scenarios apply when assigning roles to user groups.
All users in the group inherit the assigned role at the specified assignment level (project or application).
Best practices
Follow these recommendations when assigning roles:
- Use project-level roles for broad access requirements.
- Use application-level roles to assign additional or different permissions for specific applications.
- Assign roles to user groups instead of individual users whenever possible.
- Review role assignments regularly to ensure appropriate access.
