Skip to main content

Role-Based Access Control

Access controls in Sonatype Lifecycle/IQ Server, Sonatype Repository Firewall and Sonatype Advanced Legal Pack (ALP) are based on a contextual Role Based Access Control (RBAC) approach that manages access to the product capabilities and data at a level that corresponds closely to the organization’s structure and business needs governing data sharing across business units or countries.

Each user can be assigned roles with specific privileges based on the organization's data governance regulations.This eliminates the possible complexities that could be introduced by mutually exclusive roles, organization hierarchies or regulations governing business transactions for each country’s trade practices, preventing a user from performing the expected job function.

Example Scenario

Your company’s organizational hierarchy is split across multiple orgs and sub-orgs located in different geographical locations. A new user, Ellis has been onboarded for a sub-org based outside of the US. As part of your company’s data protection/sharing policies, access to Lifecycle Application Reports for orgs and sub-orgs located in the US is blocked outside the US.


Ellis needs view-only access to Sonatype Firewall Repository reports to view quarantine components across the entire company.She has been given View IQ Elements permission at the root organization level. This lets her access Firewall Repository reports in a read-only mode.However, the View IQ Elements permission also grants her the access to view application reports for all orgs and applications. This is not compliant with the data governance laws, because she is located outside the US. A common approach to resolve this issue would be to change the View IQ Elements permission context for Ellis to the org level to which she belongs (which is located outside the US.) This blocks all Application Reports that are related to the orgs in the US. This approach is compliant with the data governance laws, but also takes away access to Firewall Repository reports, due to insufficient permissions.


The built-in contextual RBAC approach, defined around the user-role relationship can be implemented here. User-role relationships are effective in addressing varying access control needs in large organizations that have users requiring different permutations of permissions to fulfill their job functions.

Defining the RBAC user-role relationship

The pre-defined Developer role, which allows view access to the assigned organization/application, can be assigned to Ellis. This will allow her to view Lifecycle data specific to the context of her org/sub-org data, but not other orgs/sub-orgs.

An additional level of access control setup at the repositories level allows a custom access control configuration. A user who is assigned the 'Developer' role (with its restrictions to be able to view org/app specific data) can be given access to view all repositories across the company. Access to Repositories can be given on a case-by-case basis, based on the users' specific job function.

This will allow Ellis to see all quarantined components, across all repositories in the company and not just those that are used for her org/sub-org.

Implementation Steps

Step 1: Select the built-in Developer role on the Roles page from the System Preferences menu.


Assign this role to Ellis for the organization they belong to (located outside the US).

Result: This will allow access to the assigned org/sub-org and block access to Application Reports for other organizations located in the US.

Step 2:Go to the RepositoryAccesscontrols.


Select Developer from the Roles dropdown on the Access page.


Select Ellis's user name from the Users and Groups dropdown.

Result: This will allow Ellis to view Firewall Repository Reports.

Step 3:Go to Orgs and Policies, and select the Organization to which Ellis belongs. This organization will contain non-US applications. Select Access.