How to use Nexus OSS User Access Management
What is Nexus OSS
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 controls
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:
Read from a repository or a subset of repositories
Administer the repository manager or specific parts of the configuration
Access specific parts of the user interface
Deploy to repositories or even just specific sections of a repository.
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 Authentication and Authorizations systems and are designed around the following security concepts:
Privileges: Rights to read, update, create, or manage resources and perform operations related to the user interface as well as the components managed by the repository manager in the various repositories. The repository manager ships with a set of core privileges that cannot be modified.
Roles: Privileges can be grouped into collections called roles to make it easier to define privileges common to certain classes of users.
Users: User can be assigned one or more roles, and model the individuals who will be logging into the user interface and read, deploy, or manage repositories as well as connect from customer tools such as Apache Maven.
Realms
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 the Administration main menu. This configuration determines what authentification realm is used to grant user access and the order the realms are evaluated.
Common Realms
Local Authenticating Realm and Local Authorizing Realm: built-in realms used by default. They allow the repository manager to manage security setup without additional external systems. The recommenced ordering is to keep the local realms at the top of the active list, that way in the event of system recovery, if you have them lower in the order (or removed), then restoration may be more difficult.
Crowd Realm: This realm identifies external storage in an Atlasssian Crowd system.
Default Role Realm: This realm will append the configured role to all users when they are authenticated
Docker Bearer Token Realm: This realm permits docker repositories with the ability to have anonymous read enabled on their repositories in conjunction with the Force basic Authentication configuration section.
LDAP Realm: Identifies external storage in an LDAP system.
npm Bearer Token Realm: This real permits users with previously generated bearer tokens to publish npm packages
NuGet API-key Realm: Is required for deployments to NuGet repositories
Rut Auth Realm: Uses an external authentication in any system with the user authorization passed to the repository manager in HTTP header field.
SAML Realm: Uses an external Identity Provider (IdP) to handle authentication
User Token Realm: Activates token-based authentication for users as a substitute for plain-text username and password authentication. When the user token capability is enabled, the realm is automatically added to the Active Realms List.
Privileges
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:
Name: The internal identifier for the privilege
Description: A human-readable description of the purpose of the privilege
Type: the Aspect of the repository manager to which this privilege applies
Permission: The internal permission definition as used by the security framework.
Privilege Types
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:
Application: These are privileges related to a specific domain in the repo manager
Repository Admin: These are privileges related to the admin and configuration of a specific repository
Repository content selector: These are privileges attributed to filtered content within a format, evaluated against a content selector.
Repository View: These are privileges controlling access to the content of a specific repository.
Script: These are privileges related to the execution and management of scripts
Wildcard: These are privileges that use patterns to group other privileges.
An example of the view:
Privilege Actions
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:
Add: This action allows privileges to add repositories or scripts.
Browse: Allows privileges to view the contents of associated repositories Unlike the read privilege, browse can only view and administrate repository contents from the UI.
Create: Allows privileges to create applicable configurations within the repository manager. Since read permission is required to view a configuration, this action is associated with most existing create privileges.
Delete: This action allows privileges to delete repository manager configurations, repository contents, and scripts. A read action is usually associated.
edit: Allows privileges to modify associated scripts, repository contents, and repo administration
read: Allows privileges to view various configuration lists and scripts. Without this action, any associated action will permit a privilege to see these lists but not its contents. The read action also allows privileges to utilize tools that can look at content from the command line.
update: This action allows privileges to update repository manager configurations. Most existing privileges with the update include read actions, in order to view the repository manager configuration updates.
*: This action is a wildcard giving you the ability to group all actions together.
Creating new privileges
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
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:
About machines and locations:
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:
External Groups mapping to Nexus Roles
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.
Users
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 in the $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:
Creating new Users
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:
Default Role
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
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.
Why not JEXL? (Why is JEXL deprecated)
JEXL based 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.
Creating a Query
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.
Managing Selector Permissions
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 Privilege button. Locate and click the Repository Content Selector from the list of options in the Privilege Type selection, and fill out the following form:
Name: Name for the content selector privilege
Description: Option description for the privilege
Content Selector: Use this dropdown to select from a list of selectors you had created
Repository: Use this dropdown to select from either a range of all repository contents, all repository contents of an individual format, or repositories created by you.
Actions: Grant read, edit, delete, or all ( * ) privileges for user access control.
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.
CSEL Reference
Some allowable attributes for content selectors that define path and format as values supported by NXRM:
Path: The path f your repository content.
format: The format of the content for which you query.
Some commonly used commands:
== : Matches text exactly,
IE format == “raw”=~: matches a Java regular expression pattern.
IE path =~”^/org/apache/commons/.*”=^: Starts with text, IE path =^ “/com/sample/”
and: Match all expressions
IE format ==”maven” and path=~”^/org/apache/commons/.*”or: Match any expression
IE format ==”maven” or format ==”npm”(expr): group multiple expressions.
IE format == “npm” pr (format ==”maven” and path =~”^/org/apache/commons/.*”)
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
Resources:
Nexus Repository OSS website: https://www.sonatype.com/nexus-repository-oss
Nexus Access Control Documentation: https://help.sonatype.com/repomanager3/system-configuration/access-control
Role-Based Access Control: Organizational User Management: https://guides.sonatype.com/repo3/technical-guides/role-based-access-controls/
Nexus Repository documentation: https://help.sonatype.com/docs?_ga=2.177040557.904573998.1591218119-1902013622.1591218119
Nexus Realms: https://help.sonatype.com/repomanager3/system-configuration/access-control/realms
Author
SEAN MALLOY
Sean Malloy is working as an Automation Engineer at Crest Data. Sean has worked on multiple automation and 508 Compliance projects for Splunk. Before joining Crest, Sean worked as an intern twice at SAP and has led multiple projects as part of his internship for Machine Learning and web development. Sean holds a Bachelor’s degree from UC Davis.