Skip to main content

Access Control

Nexus Repository uses role-based access control (RBAC) to give administrators fine-grained control over user rights to the following:

  • Access to the Nexus Repository web application

  • Read access to a component path in a repository

  • Administrator access to configuration

  • Publish or upload files to a repository

The default configuration ships with the administrator role and optional anonymous access to browse and read all repositories. You should not use the default anonymous role if you need to create protected repositories.

Tip

The default administrator role provides privilege to all aspects of the Nexus Repository system and uses the username admin. The initial password is found in an admin.password file in the $data-dir directory after startup.

Role-Based Access Controls

Nexus Repository uses RBAC to assign access based on a user's role. This follows the principle of Least Privilege by only giving access to a user based on the functionality needed to do their job. You can also align your Nexus Repository roles to external roles and groups managed in your organization's directory services. This can reduce new user onboarding/offboarding costs by delegating role assignments outside of the repository.

The following is a short example of onboarding a new team:

  1. The Apollo development team needs access to a hosted repository named dev-apollo. Members are assigned to the group in the corporate Active Directory.

  2. The Nexus Repository administrator creates a new role named team-apollo and assigns it to the Apollo group from Active Directory.

  3. The admin adds the following browse, read, and write privileges for that repository to the team-apollo role:

    • nx-repository-view-maven2-dev-apollo-add

    • nx-repository-view-maven2-dev-apollo-read

    • nx-repository-view-maven2-dev-apollo-browse

  4. Others add and remove team members to and from the Apollo group in Active Directory.

Note

Access to Nexus Repository is granted, not revoked. Access allowed by one privilege cannot be taken away by another. For this reason, the best practice is to only provide access to the resources a team needs. Using wild-card privileges (with the asterisk '*') may not be desirable in the long term as they will require a fair amount of effort to audit and roll back.