Atlassian Crowd is a single sign-on and identity management tool by Atlassian that integrates well with their suite of software engineering and collaboration tools like JIRA, Confluence and Crucible. It offers a SOAP API that allows integration into arbitrary third-party systems. Integrating a webmail system with Crowd is quite easy. I've choosen RoundCube Webmail 0.2.2 as an example. RoundCube is based on PHP and has a nice and clean user interface and a well-written code base.

Step 1: Basic Integration

There is a PHP integration library that can be used as a starting point. It provides the methods for SSO but lacks the convenience of Crowd's HttpAuthenticator. Implementing a simple PHP version of the HttpAuthenticator was the first step. My implementation uses APC to store the application token and validates every request with Crowd.

Step 2: Dovecot Masteruser

While the original version of RoundCube uses the user's username and password to connect to the IMAP store that's no longer possible with the crowdified version as it doesn't have access to the user's password. One solution is to use dovecot's masteruser feature. With that configuration in place RoundCube can access the user's mailbox by using its own password instead of the user's password.

Step 3: Configuration

That's it. Quite simple. If you like you can have a look at my patch. Check config/main.inc.php and provide the username and password of your dovecot masteruser as well as the application name, credential and service URL for Crowd.

Add a comment

Posted by Stefan Reuter on June 24, 2009 10:23:00 PM CEST #

Until now we didn't use a repository manager for Maven. Our repos were a plain directory structure on the file system served by Apache. Uploading was done using Apache's WebDAV capabilities with a simple authentication against our LDAP directory:

<Location /maven>
  Options Indexes

  DAV On
  AuthType Basic 
  AuthName "reucon Maven Repositories"
  AuthBasicProvider ldap
  AuthLDAPURL ldap://ldap.myorg.com/o=myorg?uid?sub?(objectClass=person)
  AuthLDAPBindDN uid=httpd,ou=techusers,o=myorg
  AuthLDAPBindPassword secret
  AuthzLDAPAuthoritative off

  Require valid-user
  FileETag None
</Location>

We are maintaining four repositories: one for our public Open Source artifacts and one for proprietary internal artifacts along with corresponding snapshot repositories. Access to the internal repository was limited based on an IP address range.

There are multiple reasons for us to use a repository manager:

• Unified access to repositories
  In the old days all you needed was the central repo (formerly known as ibiblio). Times have changed and now many of our projects require artifacts from a variety of different repositories. It seems many organisations prefer having their own repos instead of publishing to central. This includes SpringSource, JBoss, Codehaus and several snapshot repos like for Apache. Maintaing a list of these repos in each developers settings.xml is a pity and including them in the poms makes things even worse in the long run.
• Finer grained access control
  On the one hand we need access to our internal repo from outside of our internal network, so IP based access control no longer works well. On the other hand not all developers should be allowed to publish releases. Some kind of role based access control was needed.
• Automated creation of the Nexus index
  A Nexus index is basically a zip file containing a lucene index of the artifacts in a repository. Most Maven IDE plugins now support searching for artifacts when adding dependencies to a project. To make this work the IDE must be be able to download an up to date index of the repositories.
• Web based artifact search
  You may know mvnrepository.com a web site to search for artifacts in the central repo. I've often used it to find the correct version and maven coordinates for a dependency. A similar solution for our internal repositories would be nice.

There are a lot more reasons to use a repository manager like faster builds through caching of artifacts, black- or whitelisting of artifacts based on corporate standards but those listed above were the key factors for us.

There are three products that can be used: Apache Archiva, Sonatype Nexus and JFrog's Artifactory. There is a feature matrix that shows their features.

I dropped Archiva because its development is rather slow and it is missing some important features like grouped repositories. So Nexus and Artifactory remained. I came across two blog postings from January: Sonatype's comparison and JFrog's response. Combined they provide a lot of insight. Here is my own comparison:

Security

Good LDAP integration is a must have. Artifactory supports this out of the box, Nexus does not include LDAP support in its Open Source edition. It is a Nexus Pro feature. I do understand that Sonatype is trying to sell its Pro version but LDAP support is really a basic and vital feature. Fortunately it is not too difficult to implement a custom authenticator for Nexus and in fact there is already a project at Google Code called nexus-ldap that adds free LDAP support to Nexus. Both Artifactory and Nexus support fine grained role based authorization. One problem I faced with Artifactory was that requiring authentication seems to be a global setting, so you either require authentication for all repositories or for none. This is less flexible than Nexus which allows us to make our Open Source repository available without authentication and requires authentication only for deployment and for our internal repositories.
Artifactory has a nice additional feature that eliminates the need to store the user's password in Maven's settingx.xml in clear text by encrypting the password with a user specific key stored in Artifactory. This is an interesting approach and I would like to see this concept being used more widely (e.g. for Subversion).

Storage

How the repository manager stores artifacts and meta data is the biggest difference between Artifactory and Nexus. Artifactory uses a Java Content Repository (JCR) that can optionally be hosted in a MySQL database.
Nexus stores artifacts and meta data in the file system. It uses the maven layout so it is easy to access the repositories managed by Nexus externally. This becomes handy not only for migration but also when synchronizing to central through rsync. Though Artifactory offers an export feature having my repository data available directly on the file system makes me feel better.

Searching and Indexing

Both Nexus and Artifactory publish indexes (based on Lucene) and provide a web interface for searching artifacts stored in the repository. Nexus takes this one step futher and also allows searching for artifacts in proxied repositoreis not yet stores in the local repository. This is really handy and eliminates the need to use external sites to search for artifacts and they current version.

Conclusion

Before I found nexus-ldap I was about to choose Artifactory over Nexus. After that I prefer Nexus for the file system based storage and better searching.

References

• Sonatype Nexus
• JFrog Artifactory
• nexus-ldap: Free LDAP authentication for Nexus
• Nexus Crowd Plugin

Responses[5]

Posted by Stefan Reuter on June 16, 2009 1:23:48 AM CEST #