Privileges

Understanding Privileges

Privileges define actions which can be performed against specific functionality. Privileges can be only be assigned to roles.

To access Privileges go to Security in the Administration menu, where it’s listed as a sub-section. An extensive list of privileges is already built in the repository manager and is partially depicted in Figure: “Partial List of Security Privileges”. This feature allows you to inspect existing privileges and create custom privileges as required. Users will need nx-privilege or nx-all privileges to access this page.

Figure: Partial List of Security Privileges

Privilege Names

Names are unique identifiers. Privileges included by default are prefixed with nx- . Privileges that are migrated from Nexus Repository 2 will be named as they were in Repository 2. Privileges that you create yourself can only consist of letters, digits, underscores(_), hyphens(-), and dots(.). A privilege name cannot start with an underscore or dot(.).

For custom privileges, it is encouraged that you use a simple convention to namespace your privileges. For example using a simple acronym representing your organization name. Example Organization Inc. could prefix their privilege names with eoi- for example.

Privilege Types

The privilege list displays an icon for the privilege Type as the first column in the list.

Type	Permission Segments	Applicable Actions	Description
Application application	nexus:{name}:{actions}	create,read,update,delete	Application type privileges are most commonly the built-in privileges that control access to specific product feature areas in the Administration UI. i.e. nexus:blobstores:create,read means allow creating and reading blobstores
Repository Admin repository-admin	nexus:repository-admin:{format}:{repository}:{actions}	browse,read,edit,add,delete	Repository Admin privileges control administration of configuration for specific repositories or repository formats. i.e. nexus:repository-admin:nuget:nuget.org-proxy:browse,read means allow view of the repository configuration for the nuget format repository named nuget.org-proxy These privileges do not control access to repository content.
Repository Content Selector repository-content-selector	nexus:repository-content-selector:{selector}:{format}:{repository}:{actions}	browse,read,edit,add,delete	Repository Content Selector privileges provide fine-grained control over access to content within a repository by way of a content selector . i.e. nexus:repository-content-selector::maven2::read means allow a user read access to any content matching a content selector defined for the maven2 format.
Repository View repository-view	nexus:repository-view:{format}:{repository}:{actions}	browse,read,edit,add,delete	Repository View privileges control general access to all content contained within specific repositories or repository formats. i.e. nexus:repository-view:maven2:central:browse,read means allow browsing and viewing content within the maven2 format repository named central These privileges do not allow changing configuration of a repository.
Script script	nexus:script:{script name}:{actions}	browse,read,edit,add,delete,run	Script privileges control access to using the Groovy Script related REST APIs as documented in REST and Integration API . These privileges do not control general REST API access. i.e. nexus:script::read* means allow read access to all scripts of any name. nexus:script:my-uploaded-script:run means allow the calling user to run (execute) the script named my-uploaded-script
Wildcard wildcard	*	*	Wildcard privileges allow one to build a privilege string using a free-form series of segments. All other privilege types are more specific segment forms of a wildcard privilege. There is only one wildcard privilege included by default named nx-all with permission nexus:* that gives access to all functionality.

Privilege Permissions

Privilege permissions are represented by a colon-separated list (with no spaces after the colons) of text segments; each segment can be one of the following:

a single text value
a comma separated list of text values
an asterisk character * to represent all values in that segment

The internal segment matching algorithm uses Apache Shiro wildcard permissions.

Privilege Actions

Actions are functions allowing an explicit behavior the privilege can perform with the associated function.

You must assign one or more actions when creating new privileges; when assigning multiple actions, separate each action with a comma, but do not use spaces after the commas (e.g., "add,browse,create"). The privilege type to which you apply any of these Actions will perform the action’s implied behavior. Consider how each action behaves when applied to a privilege type:

add

This action allows privileges to add repository content or scripts.

browse

This action allows privileges to view the contents of associated repositories. Unlikeread, privilege types withbrowse can only view and administrate repository contents from UI.

create

This action allows privileges to create applicable configurations within the repository manager. Since a 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 generally associated with delete actions, so the actor can view these configurations to remove them.

edit

This action sllows privileges to modify scripts, repository content and settings.

read

This action allows privileges to view various configuration lists and scripts. Withoutread, 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 update include read actions. Therefore, if creating custom privileges with update, the actor should consider adding read to the privilege in order to view repository manager configuration updates.

*

This action is a wildcard giving you the ability to group all actions together. Using a wildcard applies all other applicable actions to the privilege.

Creating a Privilege

Click the Create privilege button to view a list of privilege types, as seen in Figure: “Choosing Privilege Types”.

Figure: Choosing Privilege Types

After selecting a type, fill in the required fields and save the privilege. 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.

Example: Creating an Application Privilege

In the following example, an Application privilege type is created:

Figure: Creating an Application Privilege

The form provides Name, Description, Domain, and Actions. In Figure: “Creating an Application Privilege” the form is completed for a privilege that allows read access to the LDAP administration. If assigned this privilege, a user is able to view LDAP administration configuration but not edit it, create a new LDAP configuration, nor delete any existing LDAP configurations.

Example: Creating a Repository View Privilege

In another example, a Repository View privilege type is created:

Figure: Creating a Repository View Privilege

The form provides Name, Description, Format, Repository, and Actions. In Figure: “Creating a Repository View Privilege” the form is completed for a privilege granting sufficient access to publish images to a specific hosted repository. A user with this privilege can view and read the contents of the repository as well as publish new images to it, but not delete images.

Privileges and Group Repositories

You can also assign privileges to users, and any assigned role, so they can have read-only access to a specific group repository. By default, these permissions will only allow users to read contents via the assigned group.

Additionally, users cannot access the contents of a group repository via members inside the group unless the member repository is assigned the same privileges as the group.

When a user is given a privilege to a group repository, then that user will also have that privilege to all transitive members of that group repository only when their request is directed to the group repository. Direct requests to individual member repositories will only work if the user is given explicit permission to the individual repository.

Group administrators also must be granted permission to both the group and all its members to manage the group configuration.

Manage Selector Permissions

As part of your security setup, you can create user permissions to manage the filters you built in the Create Selector form. You do this by creating a privilege that controls operations for components matching that selector. The privilege can even span multiple repositories.

To create a new content selector privilege, select Privileges in the Security section of the Administration panel.
Select the Create Privilege button.
Locate and selectRepository Content Selector from the list of options in Select Privilege Type.
You will see a form that displays the following:
1. Name: Create a name for the content selector privilege.
2. Description: Add a brief description for the privilege.
3. Content Selector: Use this dropdown to select from a list of selectors you created.
4. 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.
5. Actions: Grant browse, read, edit, delete, create, update, or * (applies all other actions to the privilege)for user access control.
  Note
  When granting multiple actions, do not include spaces after the comma
```
add,edit,read,browse,create,update,*
```
Save the new privilege by selecting Create privilege.

You can now use your new privilege to regulate what permissible data you want the user to access. You could group all related privileges into a role as documented inRoles. Ultimately, you could assign your roles to a user, as mentioned in Users.