When we first set out to design the external security realm (LDAP/ Crowd, etc) support in Nexus Core, we had one primary concern and that was to make it easy to integrate with systems having huge numbers of users. Nexus was designed as a tool to be used to support the largest open source communities with thousands of developers and hundreds of projects, and like most large enterprises, these communities have settled on solutions like LDAP, Active Directory, and Crowd as a way to manage user credentials and permissions. A secondary concern was to support any level of integration with these external security realms, specifically:
- delegating only authentication to an external server
- delegating both authentication and authorization to an external server
- delegating everything but authentication promotion permissions to an external server
These interactions were gleaned from years of experience working with customers at all levels. Some have completely centralized control over passwords and roles. Others have a situation where there's a global repository but the roles don't match reality, or are too hard to get updated. We wanted to create a system that would both integrate with centralized authentication servers and allow for a sensible way to override role assignments directly in Nexus.
All of this is Core functionality works the same with all types of security realms. We offer LDAP and Crowd support and the rest of this post will discuss the generic security model that works with every security realm that is available. It is possible to define multiple external realms for Authentication and/or Authorization in the Server settings. This ordered list is used to validate credentials and select roles. When a user attempts to authenticate in Nexus, it will iterate over the list until it can successfully authenticate a user.
Order Realms
For performance reasons it is almost always beneficial to move any external realms to the bottom of the list. Nexus will not check other realms once it finds a user. The first two realms are fast because the model is held in memory. The external realms tend to be slower, as they need to connect to a remote system.
Navigate to the 'Server' pane, scroll down to 'Security Settings' section, and move your external realms to the bottom of the list. (do not forget to save!)
Now that we've defined the ordering, lets take the full integration approach.
Authentication and Authorization
Lots of organizations have some central user management service which has the users identity, credentials, and which groups they belong to. Nexus is able to delegate login and authentication to that server. For authorization we map Nexus roles to your organization's roles/groups. If all your users are in a group named 'users', you can map this group to a Nexus role of the same name and assign it the desired permissions. Once a user authenticates against an external realm, their groups will match up against Nexus roles that define the specific permissions to grant.
To map a role, navigate to the 'Roles' pane and select the 'Add External Role Mapping':
A dialog will pop up, you will need to select the security realm you are using and the group you want to be mapped. This group is a group that is managed by the external server. In this case, we're mapping the "users" group in LDAP to a role in Nexus.
You then need to select which Nexus roles you want to map to your organization's group. Here you see the new role mapping. To add Nexus permissions for this group, just drag Nexus roles and privileges from the Available Roles / Privileges list to the Selected Roles / Privileges list.
By mapping the external roles/groups to Nexus Roles, we are able to grant permissions to "unnamed" users. That is, ANY user that successfully authenticates against the external realm, having the group "users" will inherit the permissions granted to the Nexus "users" role. You do not need to tell Nexus about all these users ahead of time simply to assign them roles. Imagine trying to do that for 6000 users. Nexus is unique among Repository Managers with this approach.
Authentication only
Some organizations have central user management but do not maintain user groups, or the groups are unrelated to development. For this use case, Nexus can be configured to delegate the login to the server, but all the user roles are configured inside of Nexus. This provides the benefit of allowing users to use their company wide accounts while letting a Nexus administrator manage roles.
Go to the 'Users' pane, select a user and give them a role. In the image below, I added 'Nexus Developer Role' to the user 'Maven'.
Unlike the first example, you need to manually go to each user that needs access and grant them the appropriate Nexus roles. In this model, the Nexus administrators take on more responsibility for granting the appropriate users the appropriate level of access to the repositories they need to use.
Authentication Promotion
The last option is a combination of the two previous. The User login and list of roles are delegated to a central server, but additional roles are assigned to individual users in the Nexus UI. In this model, Nexus administrators only need to augment roles for the few users that need to special permissions in Nexus. For example, user Joe Coder is a developer and is part of the organization's basic 'development' group. If Joe needs helps administer Nexus, all you need to do is assign him the 'Nexus Administrator Role'.
To assign a user a specific role or privilege, click on User in the Security menu and select the user you want to add a role or privilege to. You should see the same interface that was shown in the previous section. While the user will have a set of basic roles mapped from the external security realm, you can add special privileges that allow a user to promote a staged release or administer the Nexus interface.
In this example it is easy to see the power of Nexus's security framework. In a few clicks you can give your whole organization access to a Nexus instance. With a few more clicks you can promote a user to and admin, or just give them access to an additional artifacts.
Summary
The Nexus Core security support for External realms was designed specifically to manage several different integration scenarios from full external realm delegation to mixing and matching authentication and authorization so that it could work for any type of realm and organization. Wherever possible we made sure to imagine "will this work with 6000 users?", and this is why the role to group mapping is supported and also why we don't attempt to list all external users anywhere by default. At the lowest levels we also took care to empower realm authors to integrate in many different ways beyond just roles and permissions. A realm gets access to the exact url and http method (get/put/post/head/delete) and thus can evaluate each request using its own set of rules if desired. This is all part of our strategy to provide the most flexible and robust Repository Manager you can find.
This post focused more on the theory and mechanics of managing external realms in Nexus. If you would like to see a more end to end solution involving securing subsets of repositories, you can see Managing OSS Forges with Nexus as most of the topics covered there directly apply to organizations of all sizes.
.jpg)