Enabling Chat (XMPP) communication in Enterprise from outside Corporate Network

Lately Chat has become one of the most convenient and fastest way of  engagement among employees in large corporations. In fact it has become part of our lives and have changed the way we even imagine to contact someone. I heard one of our senior executives saying

“In late 90’s and early 21st century, employees used to use Email for exchange of information and Print Outs / letters for storing / sharing something important stuff. But lately people have started using chat communication (& other social tools) for exchanging ideas and email is primarily used for safe storage or reference kind of stuff”.

There are many situations when employees working for Large corporations are not in office but still wants to engage in Chat communication with another employee (may be for some work related issues or informing about absence from office etc).

Some of the real world use cases could be

  1. Employees working remote. They either need to connect to Corporate Network using VPN, but my personal experience it slows down performance of the machine and effects productivity. And use VPN just to connect to Corporate XMPP environment, doesn’t seems to be justified.
  2. Employees working on field, wants to quickly connect to another employee for some technical details.

But very few corporations allow use of the XMPP environment from external networks, where you can just login with your Corporate Id’s and start communicating.

Why don’t corporations open their XMPP environments to External Network :

There could be many reasons for same but one of the most common reason is few ports needs to be opened (for enabling the TCP connection) and network security team wont like it. As the XMPP server have access to many enterprise resources e.g. Active Directory , which is used for user information and authentication, XMPP server might be storing the Presence / chat details on some database, so again the Database racks or clusters are exposed to XMPP server. Security teams need to have security audit etc done and need to be really sure that there is no vulnerability which could be potentially utilised by hackers.

Another genuine problem has cropped because of the plethora of devices available these days, so not sure what device support what and what not. e.g. a client built in AIR cannot create a secure socket connection on iOS devices.

Any easy solution available to handle above problem ?

While we were building a unified communication solution for our employees, we found that by using XMPP over BOSH we can easily address most of the common problems.

Usage of BOSH (Bidirectional-Streams over synchronous HTTP) for transporting XMPP stanzas is clearly documented in XEP-0206. It basically gives a HTTP binding for XMPP communication.

Most of the XMPP servers provide capabilities to enable Chat conversation using BOSH over both HTTP as well as HTTPS. Openfire / Cisco jabber all support XMPP Communication using BOSH.

Still the question remains will the security team allow clients on external networks to directly connect to the XMPP server using BOSH ? To be honest the answer might be NO. But this is an easy problem to address.

  1. Set up a public facing hostname / domain e.g im.ent.com.
  2. On the firewall, the security team could easily write a script which will decimate the incoming request at im.ent.com and will redirect the request to the XMPP server at the rquired port if and only if the incoming request is a post call containing XMPP stanza at im.ent.com/httpbind.

Comments are closed.