Last week, I released an open-source plugin for Sonatype Nexus which integrates Atlassian's Crowd identity management server. You can read the installation instructions on docs.sonatype.org, but in this blog post I wanted to write a bit about Crowd itself and my objectives for the plugin. Read on to learn about Atlassian's Crowd and how you can use it with Nexus.
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.