Nexus OSS is a free artifact repository with universal format support. It provides a single source of truth for all your components, binaries, and build artifacts, as well as efficiently distribute parts and containers to developers. It is deployed at more than 100,000 organizations and helps centralize, store, scale, and adapt builds and packages for any software supply chain.
Nexus also provides universal support for all popular build tools, such as Maven/Java, npm, NuGet, Helm, Docker, P2, OBR, APT, G, R, Conan, and more. It also provides support for the JBM ecosystem, including Gradle, Ant, Maven, and Ivy, and helps manage components from dev through delivery with binaries, containers, assemblies, and finished goods. It is compatible with Eclipse, IntelliJ, Hudson, Jenkins, Puppet, Chef, Docker, and more.
Nexus helps development teams to be efficient and flexible by providing steam-line component sharing, insights and analytics into component security, licensing, and quality issues, and allows developers to build offline with remote package availability.
Access control is the means by which duty is explicitly applied to an individual or group. They are usually enabled through system-based controls, AKA role-based access controls. The model used is known as RBAC, which gives the gatekeeper to Nexus Repositories the authority to prescribe who or what process may have access to a specific repository, and the type of action that’s permitted. The goals of RBAC are to split up the access and controls to users with the appropriate permissions, duties, and skillsets to work on certain areas.
For organizational planning, the highest level of security is reals, which allows admins to delegate credentials for Nexus repository access, from a local instance of NXRM, admins can configure this level of security directly. The lowest level of security are content selectors, which allow admins to divide and repository into separated protected namespaces for each product, team, or project. Content Selectors are created with a special expression language syntax called CSEL, which can be used to add specific attributes to any repository.
Nexus Repository Manager OSS use RBAC that gives admins very fine-grained control over user rights to:
The default administrator user gives you private to all aspects of the Nexus Repository Manger (NXRM) and uses the username admin and the initial password which can be found in an admin.password file in the $data-dir directory after startup.
The default configuration comes with roles and users with a standard set of permissions. You can create and customize security settings to protect repositories for multiple departments or development groups. Nexus repository manager provides a security model that can adapt to the situation.
Security related configuration can be performed with the feature views available via the security section of the Administration main menu. Many of the following features are only available to users with the necessary privileges to access them. The role based access control system is backed by different Authentification and Authorizations systems and are designed around the following security concepts:
The featured view for security realms administrators allows admins to activate and prioritize security realms used for authentification by adding them to the active list on the right and placing them higher or lower on the list. The Reams view and be accessed via the Realms menu item located under Security in theAdministration main menu. This configuration determines what authentification realm is used to grant user access and the order the realms are evaluated.
Privileges control access to the specific functionality of the repository manager and can be grouped as a role and assigned to a specific user.
To access the Privileges control, go to Security in the Administration menu, where it’s listed as a sub-section. A list of privileges is prebuilt in the repository manager. This feature allows you to inspect existing privileges and create new ones.
The list has the following fields:
Click the create privilege button to view a list of privilege types. Select the corresponding are of the repository manager you wish to grant permissions. When you create a new Privilege type, you must assign at least one action in the actions field.
The privilege types are as follows:
An example of the view:
Actions are functions allowing an explicit behavior the privilege can perform with the associated function.
You can assign a single or a combination of comma-delimited actions when creating new privileges. The privilege type to which you apply any of these actions will perform the actions implied behavior.
The actions are as follows:
To save a new custom privilege, cluck the create privilege button. The privilege can be found listed among the default privileges on the main Privileges screen. You can use the filter input box to find a specific privilege.
When creating a new Application privilege, you generally need to include the Name, Description, Domain, and actions associated with the privilege.
An example of creating a new Application privilege:
When creating a new repository view privilege, you generally need to include the Name, Description, Format, Repository, and actions associated with the privilege. This form is completed for a privilege granting sufficient access to a specific hosted repository.
An example of creating a new Repository View privilege:
Roles aggregate privileges into a related context and can be grouped to create more complex roles. The Repository Manger ships with a predefined admin as well as an anonymous roles.
To inspect these roles, you can go to the view accessible via the Roles item in the Security Section of the Administration main menu. An example of the page:
To create a new role, click the Create Role button, select Nexus Role and fill out the Role Create feature When creating a new role, you will need to supply a Role ID, and a name and optionally a Description. Roles are comprised of either roles and individual privileges. To assign a role or privilege to a role, drag and drop the desired privileges from the available list to the given list under the privileges header. You can filter to narrow down the list of displayed privileges and the arrow buttons to add or remove privileges.
The same functionality is available under the Roles header to select among the available roles and add them to the list of contained Roles.
Once you have everything setup, you can press the Create Role button to get the role created. An existing role can be inspected and edited by clicking on the row in the list for the Role. This role-specific view allows you to delete the role with the delete role button. The built-in roles cannot be edited or deleted. The settings section displays the same section as the creation view.
An example of creating a new role view:
In addition to creating an internal role, the create role button allows you to create an External Role mapping to an external authorization system configured in the repository manager such as LDAP. This is something you would do if you want to grant every member of an externally managed group a number of privileges and roles in the repository manager. When in the create a new role view, select External Role Mapping, and LDAP to see a list of roles managed by that external realm in a dialog, and pick the desired group and confirm by pressing create a mapping. You can also type in a portion or the whole name of the group and it will limit the dropdown to the selected text.
Once the external role has been selected, it creates a linked role. You can then assign other roles and privileges to this new externally mapped role like you would do for any other role. Any user that is a part of this group will receive all the privileges defined in the created role allowing you to adapt your generic role in LDAP to the repository-specific use cases you want these users to be allowed to perform.
NXRM comes with two users by default: Admin and anonymous. This admin user has all privileges and the anonymous user only has read-only privileges. The initial password for the admin user can be found in an admin.password file found int eh $data-dir directory after starting the server.
The user feature view can be accessed via the Users item in the Security section of the Administration menu. The initial view lists the users alongside their User ID, First Name, Last Name and email, as well as what security Realm is elected and if the accounts status is active or disabled. The default security realm is the local NXRM realm. An example of the users display is:
Clicking on a user in the list or clicking on the Create user button displays the details view to edit or create the new user account. For external users, such as LDAP or Crowd, once you have your external realm setup you can edit their permissions here as well. Simply select the realm the user is on from the Source dropdown. Then type the user ID into the field to the right of that dropdown and search for it. Then click on the result desired to edit, same as a local user.
When creating a new user, the ID can be defined and remains fixed thereafter. In addition, you can specify the user’s First Name, Last Name, and Email Address. You must also enter and confirm a Password.
The status allows you to set an account to be disabled or Active. The roles control allows you to add and remove defined roles to the user and therefore control the privileges assigned to the user. A user can be assigned one or more roles that in turn can include references to other roles or to individual privileges.
When editing, the more button on the header allows you to select the Change Password item in the dropdown, and the password can be changed in the new dialog, provided the user is managed by the built-in security realm. For remote users, you can only edit their profiles, not create, fields defined by the remote system, such as ID will be uneditable. Ensure to change the password of the admin user to avoid security vulnerabilities, alternatively, you can create other users with administrative rights and disable the default admin user.
An example of creating a new user view:
To enable appending a default role to all authenticated users, create a new Capability (which further reading can be found here: Capability Documentation Link) using Capability type “default Role” you will then be able to select the role that you want applied to the users. Once this is saved, the default role realm will be added to the active list of security realms, and start applying the new role to all authenticated users. The default role is appended to authenticated users Dynamically, and will not show up as an assigned role to any user via the User settings page.
Content selectors provides a means for you to select specific content from all of your content, allowing you to define what content users are allowed to access. The content you select is evaluated against expressions written in Content Selector Expression Language (CSEL). CSEL is a light version of JEXL used to script queries along specific paths and coordinates available to your repository manager formats.
JEXL baed content selectors weren’t performant enough with NXRM, to address that issue CSEL was created to support changes coming in the future releases. When upgrading NXRM from an older version using JEXL, it will automatically upgrade as many of the existing JEXL selectors to CSEL selectors as possible. Any remaining JEXL electors will continue to function, but it is encouraged to perform and upgrade as soon as possible.
To create a new content selector, click on Content Selectors located in Repository from the Administration Menu, and click on Create Selector from the new menu. In the selector ID field, enter a name and an optional Description for the new selector. In the Specification section use the search expression field to build your query using CSEL syntax. You can preview your selector and what results will return by clicking the Preview Results button. On click a model will appear with the list of results. The Expression field will automatically be filled in with anything you had in the Search expression field. Similarly, any changes to Expression will be saved to the Search expression when you close the preview. An example of this:
To see results your selector would find, select a repository or grouping of repositories from the Preview Repository dropdown and click the Preview button. Assets that match will be returned in the space below the filter and can be filtered upon if you wish to check on a specific result. The Name column is also sortable in ascending or descending order. Close returns you to the content selector creation screen.
Once you are satisfied with your fields, click Create selector to create the Content Selector. All saved selector queries you create will be listed in the Content Selectors screen.
As part of the security setup, you can create user permissions to manage the filters you built in the create selector form. You can add a new privilege that controls operations such as read, edit, delete, and all ( * ), for components matching that selector. The privilege can even span multiple repositories.
To create a new content selector privilege, click Privileges in the Security Section of the Administration Panel, then click the create Privilegebutton. Locate and click the Repository Content Selector from the list of options in the Privilege Type selection, and fill out the following form:
To complete the form, save the new privilege by clicking to create privilege. Now you can use the new privilege to regulate what permissible data you want the user to access. You could group all related privileges into a role as discussed above, and you can then assign the roles to a user also discussed above.
Some allowable attributes for content selectors that define path and format as values supported by NXRM:
Some commonly used commands:
NOTE: When writing a content selector, remember that the asset’s path will always begin with a leading slash when the selector is evaluated. This is true even though the leading slash is not displayed when searching or browsing assets.
NOTE: Remember that to allow proper access when using Tree browsing in the UI, the content selectors need to include permissions for parent directories of the artifacts