Great products from Atlassian

I must admit that I've been a great fan of Atlassian, the company and its products. Great tools made for developers. Open source user, contributor and open source friendly company.
Great products, and they are Java based. Noone will ever say "Java is slow" (unless they stay in the caves, still hunting and gathering foods) when they have used Confluence or JIRA.

We used both  JIRA and Confluence at work.

I personally use Confluence for my personal content and knowledge repository.
I really liked it, just nice. Just as I need it. I can attach documents in it, version the document, attach pictures, etc. It's much better than folder or event some famous "document management". Of course only for my personal requirements point of view.

The other thing that I like is the architecture of the product, especially Confluence. It scales well, the search engine is based on Apache Lucene, it deploys stand alone on Tomcat, and also on many other application servers. It uses OSGi based on Apache Felix. So many good concept applied at the right spots. Another plus thing for me is, it supports PostgreSQL as one of the default databases for production. For me this is a big plus, as most of my personal production systems run on PostgreSQL.

Personally I think Confluence is much better structured (or architected) product than JIRA.

First, in term of the search engine, it's way much better. I don't know why JIRA couldn't have such good search capability as Confluence (e.g. it's difficult to find attachments or issues with attachments). Also the search completion as well.

Second thing is the backup and upgrade compatibility. After running for production a few years, it is so much easier to backup and restore Confluence, and it's much more difficult to backup and restore. Likewise the upgrade of versions.

Just from using such products I have learned so much for the products. Many items went into our products' wish lists... or at least my personal wish lists for our company's products.

PS: I am not related or getting paid by Atlassian. I am just a satisfied customer.

Single Sign On using Centrify DirectControl for Web and Tomcat

I was way too lazy to update my blog on Java. FYI, I am still working with Java <blink>.

Last month we have just successfully implemented a Single Sign On to Active Directory on one of our product. The Single Sign On was using Centrify DirectControl for Java/Web.
We are running on this stack:

1. Linux box for application server
1. JDK 6.0 update 31 (Centrify DirectControl requires JDK, not just JRE)
2. Apache Tomcat 6.0 (Tomcat 7.0 was not supported when we start implementing)
3. Centrify DirectControl 4.4.1-203
4. Centrify DirectControl for Java/Web 4.2.0-417
5. Red Hat Enteprise Linux 5.7 (when we started, it was still version 5.6, but now upgraded to 5.7 smoothly)
2. Active Directory
1. Windows Server 2003 or 2008
2. Active Directory 2003 or 2008
3. multi-domain forest with nested group of domain local, domain global, and universal.
4. global multi-site, replication over WAN.
3. Client
1. Windows XP Professional Service Pack 3, or Windows 7
2. joined one of the Active Directory domain.

Lots of people will associate Single Sign On with LDAP. Though LDAP most likely being involved somewhere in the Single Sign On, not every systems that use LDAP are using Single Sign On. In fact, those are just shared username/password hash database systems.

This is what I mean: if you have to login again inside your browser, definitely it is not a real Single Sign On system we are talking about.

What we implement is when you have successfully logged in to your desktop (in this case Windows XP or Windows 7), whenever you open your browser pointing to the correct URL, the web application will recognize you as the user you have logged in to Windows Active Directory domain.

We came into Centrify DirectControl because it is desired by the customer's infrastructure team for systems that run on Linux boxes.

What we learned from this implementation:

1. Implementing Single Sign On with Centrify DirectControl needs some paradigm change to the user and group that we already implemented.
2. So far Spring Security Single Sign On (Kerberos) to Active Directory that we tried only works in the lab of those who play with it, but is very difficult to replicate everywhere else. We eventually ditch our beloved Spring Security component in order to implement using Centrify DirectControl. This may change in the future, but we spent considerable amount of time without being fruitful on it.
3. On the other hand, the Centrify DirectControl for Java/Web works the first time we tried it. The sample just works.
4. Modifying the sample of Centrify DirectControl for Java/Web to a real world Single Sign On is not a trivial task though. In the instance of our client, many have tried and gave up, and we were the first one to successfully implemented it using Centrify DirectControl for Java/Web.
5. In the development site, make a working environment of Active Directory server, Active Directory client and a Linux server box is not so trivial, due to many factors that can make it fail.
1. Get the DNS setting correct is the key to successful setting of the environment.
2. Use of the tools to really diagnose, don't ignore slight problems that occurs as error messages.
6. Among of those issues that we encountered:
1. If something is wrong with the Single Sign On, usually you won't see any messages.
2. It is difficult to get the Java logging to display something the first time.
3. The forced use of old commons-logging 1.0 by CentrifyDC caused a lot of problems (we have to resolve the logging conflicts to get it working, yet because it is logging problem they won't tell you anything).
4. When you want to create installer that doesn't depend on CentrifyDC web installer, you have to really trace the dependencies one by one.
5. Some problems were caused by propagation delay or caching of Active Directory/Centrify DC/Kerberos data which simply just need to wait and try again. We encountered this several times in different places, e.g. adding user to new group but not recognized in the header, after waiting for (few) hours, it suddenly became working like magic. Yes, we tried to restart everything, leave and rejoin domain, and still the stubborn caching didn't flush at all.
6. Tomcat has unusually small default maximum HTTP header size, this kind of SSO requires bigger HTTP header size. According to our friend this also happened before with other SSO on Windows/IIS.