Managing Security in Nexus Repository 2
Nexus Repository 2
Nexus Repository Manager uses 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 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 provides 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
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.
Targets
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 assets 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.
Roles
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
Users can be assigned roles and will model the individuals who will be logging into the repository manager and reading, deploying or managing repositories.
Managing Privileges
You can access the configuration of privileges via the Privileges menu item in the Security submenu in the left-hand main menu.
The repository manager has three types of privileges:
application privileges - covers actions a user can execute in the user interface
repository target privileges - governs the level of access a user has to a particular repository or repository target
repository view privileges - controls whether a user can view a repository
Behind the scenes, a privilege is related to a single REST operation and method like create, update, delete, read.
 |
Figure 6.26. Managing Security Privileges
To create a new privilege, click on the Add… button in the Privileges panel and choose Repository Target Privilege. Creating a privilege will load the New Repository Target Privilege form shown in Figure 6.27, “Creating a New Repository Target Privilege”. This form takes a privilege name, a privilege description, the repository to target, and a repository target.
 |
Figure 6.27. Creating a New Repository Target Privilege
Once you create a new privilege, it will create four underlying privileges: create, delete, read and update. The four privileges created by the form in Figure 6.27, “Creating a New Repository Target Privilege” are shown in Figure 6.28, “Create, Delete, Read, and Update Privileges Created”.
 |
Figure 6.28. Create, Delete, Read, and Update Privileges Created
Managing Repository Targets
A Repository Target is a set of regular expressions to match on the path of components in a repository (in the same way as the routing rules work). Nexus Repository Manager is preconfigured with a number of repository targets and allows you to create additional ones. Access the management interface visible in Figure 6.29, “Managing Repository Targets” via the Repository Targets menu item in the left-hand Views/Repositories sub-menu.
 |
Figure 6.29. Managing Repository Targets
Repository targets allow you to define, for example, a target called Apache Maven with a pattern of ^/org/apache/maven/.*. This would match all components with a groupId of org.apache.maven and any components within nested groupIds like org.apache.maven.plugins.
A pattern that would capture more components like all components with any part of the path containing maven could be .*maven.*.
The regular expressions can also be used to exclude components as visible with the pattern (?!.*-sources.*).* in Figure 6.30, “Excluding Source Components from a Repository Targets” where components with the qualifier -sources are excluded. The syntax used for the expressions is the Java syntax, that is similar but not identical to the Perl syntax.
 |
Figure 6.30. Excluding Source Components from a Repository Targets
By combining multiple patterns in a repository target, you can establish a fine-grained control of components included and excluded.
Once you have created a repository target, you can utilize it as part of your security setup. You can add a new privilege that relates to the target and controls the CRUD (Create, Read, Update and Delete) operations for artifacts matching that path. The privilege can even span multiple repositories. With this setup you can delegate all control of components in org.apache.maven to a "Maven" team. In this way, you don’t need to create separate repositories for each logical division of your components.
Repository targets are also be used for matching components for implicit capture in the Staging Suite as documented in Staging Releases.