Role-Based Access Control: Organizational User Management

Repository Manager | Reading time: 6 minutes

Is this article helpful?

In this guide

What’re Role-Based Access Controls?

Access control is the means by which a duty is explicitly applied to an individual or group. They’re usually enabled through system-based controls, or to be more exact: role-based access controls. This model – known in short-form as RBAC – gives the gatekeeper to Nexus Repository authority to prescribe:

  • who or what process may have access to a specific repository
  • the type of action that’s permitted

If RBAC could be compared to a more familiar instance, let’s take a look at the areas of discipline in different section: the legal system. Consider a lawyer, a judge, and a paralegal. Each role plays an important part in this sector. However the line is drawn in the sand between skill, training, purpose, and education. Here’s where the roles diverge:

  • Lawyers tend to be front and center when addressing the judge, jury, and witnesses
  • Judges preside over court proceedings and make rulings based on her/his interpretation of the law
  • Paralegals often do a lot of the legal legwork and preparation for a case

In many cases this comparison stands on its own because the separation of duties for RBAC is more along the database management track.

Whomever has the privilege to work with this access model can make decisions based roles and permissions users need to be productive at the organization. Ultimately, enforcing RBAC policies among your humans peers – and automaton tools – is critical software security management.


We encourage you to review the following courses:

Each of these courses provide theory and practical steps to give you some grounding on access controls for the scenario in this guide.

Desired Outcomes

This guide introduces you to an organization with two administrators. They’re assigned the task of creating RBAC rules for a team specialized in Java/Maven and container management.

By the end of this guide you’ll be able to:

  • Identify the access controls suitable for your team.
  • Segregate team duties and actions to match each role in the organizational chart.
  • Configure role and permission controls in the Nexus Repository 3 UI.
  • Assign the newly configured controls to your users.

A Case for User Management

Let’s look at a hypothetical company called Organization Z (Org Z). Their staff is growing at the scale of their applications and containers. So they want to leverage their new employees to fit Nexus Repository’s RBAC specifications. Org Z hires two new administrators — Barbara and Patrick — and a crew of engineers. Org Z wants the admins to create, organize, and integrate a record of roles and responsibilities into a hierarchy based on engineers hired.

Barbara is given the assignment to configure access controls to a team called “Gaia”. “Gaia” is a small team that develops Java applications. Barbara works with fellow administrator, Patrick, who’s given the task of assigning security policies to Docker engineers. This team is called “Chronos”.

Regardless of team, the highest level of security is the realm. Realms allow Barbara and Patrick to delegate credentials for Nexus Repository access. From a local instance of Nexus Repository, Barbara and Patrick can configure this level of security directly in the repository manager.

The lowest level of security are content selectors. Selectors allow your administrator to divide a repository into separated (protected) namespaces for each product, team, or project. They’re created with a special expression language syntax called CSEL. This can be used to add specific attributes to any repository.

Defining users and roles is based on how the organization operates and delivers the end-product. The actor responsible for enabling or limiting actions are the duties of an administrator. In Nexus Repository, you can use the RBAC model to access rights to group individuals by role name, and use the resources to restrict individuals authorized to assume an associated role.

Separation of Duties

Now that we’ve quickly established points of contact for each group, use the company’s organization chart to breakdown the roles and responsibilities.

Both teams will be assigned a lead. Alice is chosen to be the head of “Gaia” developers. For “Chronos”, Leo will be at the helm. On the administrative front, Barbara and Patrick oversee “Gaia” and “Chronos” respectively.

Team ‘Gaia’

From the organizational chart, Alice (“Gaia”) leads. Kwame, Genji, and Helios all serve as contributors with equal access to download, modify, and commit changes to their repositories.

With the administrative role, Barbara can create repositories and storage for components. She can also assign the full list of database actions for Alice. The rest of the team will only be able to work within parts of the repository partitioned off to an assigned role.

Team ‘Chronos’

The same rules and policies will apply to Patrick who oversees system configuration for “Chronos”. “Chronos” includes two Engineers-In-Test: Laura and Ernest. They write self-contained integration tests, enforcing best practices under Leo’s lead.

User-Role Matrix

Here’s a table of all roles, responsibilities, and actions:

Title Role(s) Project Actions
Barbara Administrator “nx-admin” - CRUD and BREAD
Patrick Administrator “nx-admin” - CRUD and BREAD
Alice Lead Java Engineer “gaia”, “dev-lead”, “dev-test” foo1, foo2, foo3 BREAD
Kwame Java Engineer “gaia” foo1 browse, read, edit, add
Genji Java Engineer “gaia” foo1 browse, read, edit, add
Helios Java Engineer “gaia” foo1 browse, read, edit, add
Leo Lead Docker Engineer “chronos”, “dev-lead”, “dev-test” foo1, foo2, foo3 BREAD
Laura Docker Engineer-in-Test “chronos”, “dev-test” foo1, foo2, foo3 browse, read, edit, add
Ernest Docker Engineer-in-Test “chronos”, “dev-test” foo1, foo2, foo3 browse, read, edit, add
Leia Docker Engineer “chronos” foo2 browse, read, edit, add

Now, it’s time for Barbara and Patrick to add the individual and team specifications to the repository manager.

Assign Attributes

Assuming there’re existing proxies for Maven repositories and a registry for Docker, Barbara and Leo will need to:

  1. Create Docker and Maven hosted repositories.
  2. Create the roles and grant desired repository access to the roles.
  3. Assign the roles to the users.

The attributes will vary due to each team member’s skills and responsibilities. Barbara and Patrick will need to do the following:

  1. Write a content selector expression for the respective format (or project).
    • for team “Gaia” add format == "maven2" && path ==*.foo1."
    • for team “Chronos” add format == "docker" && path =~ '^/v2/library/(foo2|foo3).*$'
  2. Create a Content Selector Privilege, one for each team.
    • Add a name, description, and apply the CSEL markup into the Search expression field.
    • Optionally, use the Preview Results option to apply the search expression to appropriate repository.
  3. Create the following roles: gaia, dev-lead, and dev-test.
  4. Grant the privileges to each of the roles: gaia, dev-lead, and dev-test.

Additional Resourses

The Customer Education team always appreciates feedback, suggestions, and recommendations from you. If you need immediate support for this guide check out the resources in our help docs. Learn about role-based access controls in the Security chapter. In our support knowledge base you can also refer to the security reference guide.

To see a demo on configuring roles watch this 4-minute video on our YouTube channel.

Of course, don’t hesitate to join our community. You can search from the field on the top right for questions and answers. You can also post a question/new topic of your own.