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 chose 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

Responses[2]

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

There is a problem with the maven-release-plugin when used with recent versions of Subversion. It stared at version 1.5.1 of Subversion and made the release:prepare command fail because Maven was no longer able to tag the release.

You may have encountered the following error with release:prepare:

svn: File '...' already exists

One reason for this can be SCM-406.

For some time I've worked around this issue by doing my releases on a machine with an older version of Subversion.

A better solution is to use the latest version of the maven-release-plugin (2.0-beta-9 at the moment) and set the remoteTagging property to true:

<build>
  <plugins>
    <plugin>      
      <artifactId>maven-release-plugin</artifactId>
      <version>2.0-beta-9</version>
      <configuration>     
        <remoteTagging>true</remoteTagging>
        <preparationGoals>clean install</preparationGoals>
        <autoVersionSubmodules>true</autoVersionSubmodules>
        <tagBase>...</tagBase>
      </configuration>
    </plugin>     
  </plugins>
</build>

Keep in mind that you should always specify the exact version of the plugins you are using. This not only makes sure you get what you need it also ensures that the build is reproducible in the future and works consistently accross different machines.

Add a comment

Posted by Stefan Reuter on May 30, 2009 3:58:00 PM CEST #

Thomas has a nice example of how Deutsche Lufthansa has leaked personal data through an entertainment site operated by an external agency.

Most companies have strict rules for handling personal data and installed security policies for secure handling of sensitive information. Therefore enterprise data centers are usually quite secure. However the corporate processes that are required to keep the standards high are slow and expensive. This causes some companies to skip them in favor of faster and cheaper alternatives.

One solution is to accept hosting offers by the agencies that build the sites. The problem is that they are seldomly capable of providing a secure environment. It's just not their business. The result is that sites with sensitive data are operated in shared hosting environments by unskilled persons out of control of corporate IT. It's only a matter of time until security issues pop up and companies can be glad if they are informed before any data is stolen.

It just doesn't make sense to harden the front door if you open up a few back doors at the same time. The best security policies are worthless if companies are willing to bypass them for faster and cheaper alternatives. Maybe Thomas' story will help showing the value of corporate IT to those seeking alternatives without looking at the consequences.

Add a comment

Posted by Stefan Reuter on May 26, 2009 1:27:00 PM CEST #

As DECT is mostly broken it was time for some new mobile handsets.

We are already using Asterisk for our communication so the new mobile handsets are required to work well with it. Communication should be secure and ideally the handset would also be a mobile (GSM) phone that could be carried along when leaving the office.

Our choice was the Nokia E63. It supports quad-band GSM, UMTS, SIP and WLAN IEEE 802.11b/g including WEP, 802.1X, WPA and WPA2. Combining GSM and SIP + WLAN works out great. In the office we directly receive landline and VoIP calls to our mobile. When we are away Asterisk detects the missing phone and either routes calls to the mobile number or sends callers to the mailbox.

The solution is affordable, based on open standards, secure and very user friendly.

Add a comment

Posted by Stefan Reuter on May 1, 2009 1:31:32 PM CEST #

JBoss AS 5.1.0-CR1 is out and finally includes a brand new admin console:

After installing JBoss AS 5.1.0 you can access it at http://localhost:8080/admin-console. Login with user "admin" and password "admin".

The project behind the admin console is Embedded Jopr a web-based application for managing and monitoring an instance of JBoss AS. It is the little brother of Jopr. Jopr is a full-fledged systems management tool that helps managing and monitoring multiple instances of JBoss AS, Apache Webserver, Tomcat and more. The advantage of Embedded Jopr is that it is available out of the box and does not need any external resources like a database or separate agents. I am sure it makes operating JBoss AS a lot easier and more fun.

Give it a try and download the latest version.

Add a comment

Posted by Stefan Reuter on April 30, 2009 12:28:00 PM CEST #

After my old chair was more and more broken I decided to buy a new one. After some research I chose the Embody by Herman Miller.

The chair was delivered yesterday and it is just great. Its covering is like skin and lets the air flow through. The chair supports your movements and feels very comfortable.

For me this chair is part of the ideal workspace for software development which consists of

• a fast computer with lots of memory
• two big screens
• a phone with good support for hands free calls
• a cheap desk
• a great chair
• a calm environment
• enough coffee

References:

• Embody Chairs brochure

Responses[1]

Posted by Stefan Reuter on March 5, 2009 4:46:00 PM CET #

I've updated Open Archive for the latest version of Openfire and fixed a few bugs. Dele is about to add support for it to the Red5 SparkWeb client.

Open Archive is a XEP-0136 compliant server side message archive for Openfire. It is available as a plugin from here.

To install the plugin just rename the jar to archive.jar, place it into the plugins folder of your Openfire server and enable it in the Openfire console at Server Settings/Archive Settings.

For those interested in the source code have a look at its development site.

Update

Dele has published an updated version of the Red5 plugin that makes use of Open Archive. You can download it from http://red5.4ng.net/red5-0.1.07.zip.

Add a comment

Posted by Stefan Reuter on December 17, 2008 5:47:00 AM CET #

This is a short step-by-step howto that shows how I've installed OpenVPN on OpenSolaris 2008.11.

Step 1: Install GCC

# rolemod -K type=normal root
# pkg install SUNWgcc

Step 2: Install the TUN/TAP Driver

Grab the TUN/TAP driver for Solaris, unpack it in /usr/local/src and configure it:

# mkdir -p /usr/local/src
# cd /usr/local/src
# wget http://www.whiteboard.ne.jp/~admin2/tuntap/source/tuntap/tuntap.tar.gz
# tar xvfz tuntap.tar.gz
# chown -R root:root tuntap
# cd tuntap
# ./configure

On 64bit you must modify the generated Makefile to call ld with the correct options. Add a LDFLAGS variable and replace $(LD) by $(LD) $(LDFLAGS):

LDFLAGS = -melf_x86_64
...
modules: tun.o tap.o
        $(LD) $(LDFLAGS) -r -o tun tun.o
        $(LD) $(LDFLAGS) -r -o tap tap.o

Run make and make install. The errors from /usr/sbin/rem_drv can be ignored as the module usually wasn't installed before so it obviously can't be removed.

Step 3: Install OpenVPN

Grab the latest RC of OpenVPN 2.1 (currently 2.1rc15) and unpack it in /usr/local/src:

# cd /usr/local/src
# wget http://www.openvpn.net/release/openvpn-2.1_rc15.tar.gz
# tar xvfz openvpn-2.1_rc15.tar.gz
# chown -R root:root openvpn-2.1_rc15
# cd openvpn-2.1_rc15

You must replace tun.c from OpenVPN with the corresponding patched file:

# wget -O tun.c http://www.whiteboard.ne.jp/~admin2/tuntap/source/openvpn/2.1/tun.c
# ./configure --disable-lzo
# make
# make install

If you do not disable LZO compression you must install the LZO library and headers before. We don't use it so we don't bother.

The OpenVPN binary is now available in /usr/local/sbin/openvpn.

Step 4: Configure OpenVPN

Configuration of OpenVPN is not different on Solaris than on any other supported platform. You can find the detailed documentation in the OpenVPN Howto.

If you get a Can't set PPA 1: File exists (errno=17) error and OpenVPN exits the tun interface may still be plumbed. Remove it with

# ifconfig tun0 unplumb

Responses[7]

Posted by Stefan Reuter on December 17, 2008 2:27:00 AM CET #

We are currently building a web application for the financial services sector that is highly depending on client side JavaScript and DOM manipulation. Each time the user changes an input parameter the following steps are executed:

• the data is collected from the user interface,
• sent to the server,
• processed there,
• sent back to the browser
• where the user interface is finally updated with the results.

The application is based on DWR for Ajax communication, Drools as a rule engine running on the server and some custom Java code. Server side execution is rather fast, in the range of 100-200ms. On the client side things are different. Collecting the data is quite fast, too, below 100ms in every browser. Updating the UI is where most of the time is spent.

The user interface contains a bunch of tables to show the results. Rows are created and removed dynamically depending on the returned data and populated with the corresponding properties. This is done using jQuery for heavy DOM manipulation.

The current version of the tool has been tested with different browsers showing some significant differences:

These are just the numbers from our current development version (IE 6 matches the production environment, that's why we didn't test with IE 7 or IE 8 beta).

What is interesting is that Google Chrome with the WebKit HTML and V8 JavaScript engine outperforms Firefox by a factor of three and IE 6 by a factor of six. As Safari is also quite fast this seems to result mostly from the WebKit rendering engine.

Responses[1]

Posted by Stefan Reuter on November 29, 2008 4:21:00 AM CET #