Installing the Nexus Atlassian Crowd Plugin

When you downloaded Nexus Professional, you also download a few optional plugins including the Nexus Crowd plugin. This plugin is located in the ${NEXUS_HOME}/runtime/apps/nexus/optional-plugins directory under security-crowd-realm-1.4.0. To install this plugin in Nexus:

* Copy the security-crowd-realm-1.4.0/ directory from ${NEXUS_HOME}/runtime/apps/nexus/optional-plugins to ${NEXUS_HOME}/runtime/apps/nexus/plugin-repository.
* Once the optional User Account plugin has been copied to the plugin-repository/ directory, restart Nexus and the User Account plugin will be installed.

Configuring the Crowd Plugin

Once the Atlassian Crowd plugin is installed, restart Nexus and login as a user with Administrative privileges. To configure the Crowd plugin, click on the Crown Configuration in the Securty section of the Nexus menu as shown in the following figure.

Clicking on the Crowd Configuration link will load the form shown in the next figure. This configuration panel contains all of the options that needs to be configured to connect your Nexus instance to Crowd for authorization and authentication.

Adding the Crowd Authentication Realm

Once you have configured Nexus to connect to Crowd, you must select the Crowd authorization realm from the list of available realms in your Nexus Server settings. This next figure shows the Security settings section in the Nexus Server configuration. To load the Nexus server configuration panel, click on Server under Administration in the Nexus menu. Drag Crowd from the list of available realms to the list of selected realms and then save the Nexus server configuration.

Configuring a Nexus Application in Crowd

To connect Nexus to Atlassian’s Crowd, you will need to configure Nexus as an application in Crowd. To do this, login to Crowd as a user with Administrative rights, and click on the Applications tab. Once you click on this tab, you should see two options under the Applications tab: Search Applications and Add Application. Click on Add Application to display the form shown in the following figure and create a new application with the following values in the Details tab of the Add Application form:

* Application Type: Generic Application
* Name: nexus
* Description: Sonatype Nexus Professional

In this next tab you will need to configure the application connection for Nexu. You need to configure the URL of the application and the remote IP address. The next figure shows the Connection form configured for a local instance of Nexus. If you would configuring Crowd and Nexus in a production environment, you would supply the URL that users would use to load Nexus in a web browser and you would supply an IP address which was not the loopback, 127.0.0.1 address. Once you have completed the Connection form, click on Next to advance to the Directories form.

Custom Role and User Mapping

That is all there is to configuring Nexus Professional to integrate with an Atlassian Crowd instance. After you’ve connected Nexus to Crowd you can map Crowd roles to Nexus roles, and you can customize Nexus roles granted to Crowd users. For more information about the integration between Atlassian Crowd and Sonatype’s Nexus Professional, see the Crowd chapter of the Nexus book.

Luke Kanies, the creator of Puppet, commented in his last entry about Open Source business models, specifically the idea of an Open Core and what that means. As an Open Source company do you have an open version of your product that’s crippled? Or do you an open version of your product that is truly useful? This was the crux of the questions I asked all the Sonatype CEO candidates, and this turned out to be the reason it took me almost 8 months interviewing 17 candidates to ferret out the right person. It was a grueling process finding Mark de Visser but I was adamant and our VCs, Hummer Winblad & Morgenthaler, were very patient and let me take my time to find the exact right match. I got pretty ornery at one point &emdash; I thought I would never find the right person in Silly Valley.

• The Open Source product you provide to users must be great: the Open Core should stand on its own as something truly useful without any additional commercial add-ons. The software must perform well in a production environment.
• The Open Source product you provide should go through an ungodly amount of testing and QA. Testing and QA on the Open Core are the cornerstone of quality and should not be reserved for commercial versions of your product.
• The Open Source product you provide should be architected such that all commercial features are plug-ins to the Open Core.
• The Open Source product you sell should have completely open pricing. If someone cannot clearly see what your pricing is and what the difference is between your open and commercial versions, you likely have a predatory and opportunistic pricing model.

At Sonatype with our first product, Nexus, I can say that I feel internally consistent about our process and our products. I’m satisfied that we have achieved the right balance between our Open Core and the commercial plugins. I feel internally consistent about the way we have participated as individuals in the community. While I’ve spent a decade contributing to open source software, I’m also aware that I occasionally need to eat.

Nexus’ Open Core

The Open Source version of Nexus is good and stands on its own. People can use it in production environments. We have an enormous amount of integration tests with coverage reporting. We have dedicated QA staff, and we’ll be taking the next step with help from Patrick Lightbody to setup completely automated, x-browser, Selenium testing in mid-March. We have a book on Nexus that is free. Being open and not hiding the online documentation behind registration has been a good thing for the community

We have a modular platform where the commercial features are a clear superset of the Nexus core. We have no special branches for the Nexus core for the commercial version. All of our QA and testing for the core happen in the open. Our commercial SCM contains nothing but plug-ins and our build simply drops those plug-ins into the core structure where they detected on startup and activated.

In a Nexus plugin core functionality can be added, UI features, REST services, and security capabilities. When a plugin is detected all of these capabilities contribute to well defined extension points in the Nexus core and are automatically wired in. We have no additional code for the core in the commercial version of Nexus. We don’t need to. We are still working through our APIs but users in the community have already contributed plug-ins (the first was a plugin to integrate Nexus with Atlassian’s Crowd product) and everyone will be able to extend Nexus in the same way Sonatype does. That does mean we have to make sure that we provide a lot of value in the commercial version and that’s fine with us.

Open Pricing Model

Our pricing model is also completely open. I think without question that Atlassian has this right. Atlassian is more like an Open Source company then most Open Source companies. If you show everyone the same thing you don’t have to remember the variations that are just going to get you in trouble. If you don’t have a clear pricing model driven by channels and inside sales you’re just dead as a company. The days of enterprise elephant hunting is over. Potential customers who start out as your Open Core users need to see exactly what they get and how much it costs. If they can make all the decisions by easily trying your commercial product and comparing features then you have a viable company. It’s all predicated on being truly open.

What is Crowd? (or why not just use LDAP)

Atlassian refers to Crowd as an Single-Sign On and Identity Management Server. This basically means that Crowd is a directory server that allows you to manage users, groups, and roles. Atlassian provides Crowd integration libraries for all of their products (‘natch), Apache, Subversion, and Jive Forums, Acegi, and Spring Security, as well as a generic Java client. Crowd can be used in many scenarios where an LDAP server could be used, but differs from LDAP servers in the following ways:

• Crowd is specifically designed for user management. As a result, the API is significantly simpler than most LDAP APIs
• Crowd provides a SOAP-based Web Services API.
• Crowd is designed to multiplex directories. This allows you to combine multiple directories in a way that is transparent to client applications. These directories can be backed by a database, LDAP server, Active Directory server, or using entirely custom logic.
• Each client application which uses Crowd can have a uniquely defined view: which directories are included, which users will be able to authenticate, etc..

Crowd also can act as an OpenID provider and has limited support for SAML, largely to support Google Apps.

I was drawn to Crowd after doing many different LDAP integrations and running to what I saw as roadblocks to agility. Crowd is easy to mock, easy to administer, and easy to develop against.

Plugin Objectives

Starting with version 1.1, it has been possible to use alternate authentication mechanisms within Nexus. With this in mind, the objectives for the Crowd plugin were pretty straightforward:

• Authenticate users against Crowd.
• Get the list of user roles from Crowd.
• Define the permissions for each role in Nexus.

This last point was particularly important. The Nexus permission model is (necessarily) complex with support for repository-specific permissions, nested roles, and the potential for permission to be added by plugins or in future releases. As such, it seemed to make the most sense to have user/role mappings done in Crowd, but the role/permission mappings done inside Nexus.

In Nexus 1.1, accomplishing these objectives involved a substantial amount of boilerplate code involved in order to accomplish the last objective. With Nexus version 1.2, support for external authentication sources was substantially improved and the Crowd plugin was rewritten to take advantage of those improvements.

Future Goals

Moving forward, the two substantial improvements identified for the plugin are a configuration user interface and support for Single Sign On (SSO). If you have additional suggestions for plugin features, please raise those via JIRA or on the Nexus mailing list.