Documentation Nexus Repository Manager 2.14

6.12. Managing Security

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 more roles.
Users can be assigned roles and will model the individuals who will be logging into the repository manager and reading, deploying, or managing repositories.