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
- Administator 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.
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 to outside of the repository.
The following is short an example of onboarding a new team:
- The Apollo develop team needs access to a hosted repository named dev-apollo. Members are assigned to the group in the corporate Active Directory.
- The Nexus Repository administrator creates a new role named team-apollo and assigns it to the Apollo group from Active Directory.
- 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
- Others add and remove team members to and from the Apollo group in Active Directory.
Access to Nexus Repository is granted, not revoked. Access allowed by one privilege cannot be taken away by another. For this reason, the best pratice 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.
Related Topics
Realms
The Realms section in Nexus Repository allows you to activate and prioritize security realms used for authentication and authorization.
Privileges
Privileges can only be assigned to roles, and they define the actions that a role can perform against specific functionality. Nexus Repository ships with a set of core privileges that cannot be modified. Nexus Repository automatically adds privileges for new repositories when they are created.
Roles
Roles aggregate privileges into a related context and can even be grouped to create more complex roles. Rather than assigning individual privileges to individual users, you assign privileges to roles to make it easier to manage users requiring similar sets of privileges.
Users
A user is an individual Nexus Repository account attached to a single email and password.
Content Selectors
Content selectors allow you to configure access to a specific namespace or repository location. Content selectors are added to custom privileges to grant access to those resources.
Default Role
You can use the Default Role capability to create a role with a common set of privileges that Nexus Repository automatically grants to all authenticated users. This is useful for allowing a standard level of access to everyone within your organization who can authenticate through your configured Realms.