powered by Jive Software

Restrict Openfire to custom client


I’m currently developing a xmpp client/server application with an Android app with the Asmack library as the client and a customized Openfire server (I added some protocol extensions). As the server will be public my question is, how can I restrict the access so only my custom client is capable to communicate with my customized public server. Is there any kind of auth mechanism like sending an global client auth token to the server?

Thanks for your help!

You may want to take a look at the Client Control plugin for Openfire. You will find it under:

Openfire admin page --> Plugins --> Available Plugins --> Client Control

Now, after install, go back to the Server tab then the sub-tab Client Management --> Permitted Clients.

As-is, the plugin can allow/block a few different common XMPP clients, but I’m sure you can go in and modify it to allow your custom client and disable all others. I’m not sure how it works exactly, but my guess is it uses the base resource name or something to guess which client is trying to connect.

As far as i know this plugin is only using base resource name and so can be easily fooled. zersaegen will have to create some other way (like a client sending a secret token and the server only accepting clients who is sending this secret token). There is no special auth mechanism for this in Smack or Openfie (other than that simple plugin) as xmpp is an open technology and blocking clients isn’t a priority feature.

1 Like

Hello all,

I just spent some time figuring out how Add Additional Client works in the Client Control plugin by sniffing client/server traffic.

Whatever client names you enter into the Server\ Client Management\ Permitted Clients list will be searched for by the Client Control plugin after OpenFire prompts the user with an XMPP Service Discovery request (see: http://xmpp.org/extensions/xep-0115.html & http://xmpp.org/registrar/disco-categories.html#client [note the “name” parameter is optional and not described in the spec]).

The given string (the client name or any part of the name) will be included in a case-insensitive search of the http://jabber.org/protocol/disco#info response’s identity name parameter.

For example, Pidgin’s response:

<query xmlns='[http://jabber.org/protocol/disco#info](http://jabber.org/protocol/disco#info)'>

<identity category='client' type='pc' name='Pidgin'/>



So you can add “idg” or “gin” or “pid” or “pidGIN”, and the plugin will allow the client.

Therefore, although it won’t be perfect, you can do the following to reduce the chances that a rouge client connects to the Openfire server:

  1. utilize the “name” parameter as a sort of “shared secret” (obviously retrivable via the client… but having an locally accessible encrypted datastore and allowing your client access to this datastore would be interesting solution [note process explorer is an example of a program that can easily read strings in a process’s memory])

  2. utilize client certificates for authentication.and your own CA.

  3. look into application whitelisting (applocker for instance).

Not perfect, but #1 is an example of how you can utilize the Client Control plugin as a sort of gatekeeper.

It is spoofable of course… check out http://www.wildcroftsecurity.com/echo-mirage

Good luck,


1 Like