Company-Wide Instant Messaging with Jabberdby Oktay Altunergil
Instant messaging has quickly become part of everyday life in the last decade, with Mirabilis's ICQ leading the way and a host of others following. However, the idea of being notified of the presence of other people when they are online and being able to communicate with them instantly dates further back. Even before ICQ came out, some versions of Unix included simple tools to poll a remote server periodically to see whether a particular user was logged in and notify the user via a small GUI application of their presence. From then on, a host of applications including
talk were available for this type of communication. This worked considerably well when the internet-using population comprised university students and people who worked at government organizations and corporations. Because almost everyone logged in to the network using some kind of a host machine with a real shell on the system, people could communicate with their friends and colleagues using only the simple tools Unix always provided.
With the internet becoming available to the masses from the comfort of their homes (albeit with no shell account to speak of) and becoming a much more hostile environment, causing server administrators to deny other hosts to poll their servers inquiring about the users logged in, the old method of instant communication became impractical. The need arose to provide an easier and more versatile way to communicate, and various companies came out with their own implementation of the instant-messaging solution, often with proprietary protocols and server software doing the work.
Today's instant-messaging landscape looks much different from ten years ago. Major players in the field are multimillion-dollar corporations that see instant messaging as just another business opportunity--another way to deliver their own messages to millions. For better or worse, the efforts of the corporations have paid off and instant messaging has become very commonplace, with people starting to exchange instant-messaging IDs instead of phone numbers or even email addresses. As with many other areas of technology built around proprietary offerings, someone sooner or later would offer an open standard. In instant messaging, the leader here is Jabber.
Jabber is an open, XML-based protocol for instant messaging and presence. One of the more visible applications of this protocol is the creation of an instant-messaging network, though the protocol itself allows the development of and use with many other applications.
Apart from the philosophical benefits of Jabber, one great advantage is the absolute openness of both the Jabber protocol itself and a variety of open source software projects (some also conform to the FSF's description of free software) that implement the protocol. Without this, few companies would have the resources to accomplish the solutions described in this article.
Consider a hypothetical midsize company with multiple branch offices in multiple locations. The company employs between 200 and 400 employees, and the security of internal communications is of extreme importance. The employees use a mixture of Windows and various flavors of Linux and BSD on their workstations, and expect to be able to use the messaging system when home or on the road. Another crucial requirement is that the system authenticate against the existing Microsoft Active Directory domain controller. This will allow the central management of employees' access to the messaging system.
The instant-messaging needs of this hypothetical corporation dictate:
- The secure transfer of messages
- The ability to handle from 200 to 400 employee accounts
- Client software for Windows, Linux, and BSD (hybrid desktop environment)
- Access from outside the WAN
- The use of the existing Active Directory domain for user data
- The authentication of users by their Active Directory domain credentials and access rights
Although they're not part of the requirements, I'll also throw in a few freebies just for good karma. These should go a long way toward ensuring a successful deployment of the system and acceptance by users, at least in the introduction stage.
- Pre-populate all users' rosters (buddy lists) so users don't need to add people manually. (Due to client resource and space constraints, this is only practical for up to a few hundred users who are not all online at once.)
- Add new users to the rosters of all existing users automatically.
- Remove from existing rosters those users who leave the company automatically.
- Make the system more highly available by automatically restarting in the event of failure.
- Do not offer or implement conversation logging. I include this here because of my belief in privacy. Some might argue that it's the corporation's right to spy on its employees. I disagree.
As a side note, this solution also intentionally leaves out some features that your organization might desire. Logging is one, file transfers is another. At the time of this article, there is no single preferred method for securely exchanging files with low overhead and universal client support. Various Jabber Enhancement Proposals (JEPs) address that; these will be part of the Jabber protocol in the future.
Alternatives to Using Jabber
There are many alternatives to using Jabber as an instant-messaging solution.
Publicly available instant-messaging networks
One option is to use a publicly available instant-messaging network. Those include MSN Messenger, Yahoo Messenger, AOL Instant Messenger, and ICQ. Although arguments against using these public networks in a corporate environment should be pretty self-evident, in practice many corporations either embrace the use of a particular public instant-messaging network or do not have policies against using these services, and employees end up using their existing user accounts on these networks for work purposes.
Some of the more obvious drawbacks to using a public network in a corporate setting are;
- Security cannot be enforced based on the corporation's needs.
- Data resides on the provider's servers and in some cases becomes its property.
- The corporation cannot block access to the network based on its needs.
- The corporation has no control over the stability and availability of the network.
- The corporation cannot automate processes such as adding new employees to existing rosters.
- Major public IM networks such as ICQ have blocked access to entire countries at times.
Hosted, subscription-based solutions
Many players in the public instant-messaging space also provide enterprise versions of their software, in which they host a corporation's instant-messaging domain on the provider's servers. These usually include additional features for security and automation. While this is better than using a public network, there are still some drawbacks:
- Data still resides on the provider's servers and is only as secure as the provider decides to make it.
- Privacy concerns may arise when the provider has access to all conversations.
- Although automation is possible, it will not be as flexible.
- Subscription costs are usually high.