Nexus Repository Manager Pro and Nexus Repository Manager OSS use role-based access control that gives administrators 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 configuration ships with roles and users with a standard set of permissions. As your security requirements evolve, you will likely need to customize security settings to create protected repositories for multiple departments or development groups. Nexus Repository Manager provides a security model that can adapt to any scenario.
The default administrator user give you full control and uses the username admin and the password admin123.
This section covers all aspects of security of the repository manager including:
- user account and access right management related to user interface as well as to component access documented in Privileges, Roles and Users
- selection of security backend systems called Realms including the built-in system as well as LDAP and others
- management of SSL certificates from remote repositories, SMTP and LDAP servers documented in Configuring SSL
Security-related configuration can be performed with the feature views available via the Security section of the Administration main menu. Many of the features shown in this section 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 as documented in Realms and designed around the following security concepts:
Privileges are 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.
Privileges can be grouped into collections called roles to make it easier to define privileges common to certain classes of users. For example, administrative users will all have similar sets of permissions. Instead of assigning individual privileges to individual users, you use roles to make it easier to manage users with similar sets of privileges.
Users 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 client tools such as Apache Maven.