Available in Nexus Repository OSS and Nexus Repository Pro
Nexus Repository Manager Pro and Nexus Repository Manager OSS use a role-based access control (RBAC) system that gives administrators very fine-grained control
over who can read from a repository (or a subset of repositories), who can administer the server, and who can
deploy to repositories. The security model in the repository manager is also so flexible as to allow you to
specify that only certain users or roles can deploy and manage components in a specific repository under a
specific groupId or asset class. The default configuration of Nexus Repository Manager Pro and Nexus Repository Manager OSS ships with four roles and four users
with a standard set of permissions that will make sense for most users. As your security requirements evolve,
you’ll likely need to customize security settings to create protected repositories for multiple departments or
development groups. Nexus Repository Manager Pro and Nexus Repository Manager OSS provide a security model which can adapt to any scenario. The security
configuration is done via menu items in the Security submenu in the left-hand main menu.
The RBAC system is designed around the following four security concepts:
Privileges are rights to read, update, create, or manage resources and perform operations. The
repository manager ships with a set of core privileges that cannot be modified, and you can create new privileges
to allow for fine-grained targeting of role and user permissions for specific repositories.
Privileges are usually associated with resources or targets. A target can be a specific repository or a
set of repositories grouped in something called a repository target. A target can also be a subset of a repository
or a specific set of assests within a repository e.g. all javadoc archives only. Using a target you can for
example also apply a specific privilege to a single groupId and all components using it.
Collections of privileges can be grouped into roles to make it
easier to define collections of privileges common to certain classes
of users. For example, deployment users will all have similar sets of
permissions. Instead of assigning individual privileges to individual
users, you use roles to make it easier to manage users with similar
sets of privileges. A role has one or more privileges and/or one or
Users can be assigned roles and will model the individuals who will be logging into the repository manager
and reading, deploying, or managing repositories.