Jabber/XMPP

Une évolution dans l'envoi de messages.

3 octobre 2003

fabrice@gadaud.org

Introduction

Jabber est le nom original du protocole développé à partir de 1999 par Jeremie Miller, dont l'implémentation est réalisée à travers jabberd, un serveur OpenSource. Depuis environ 2 ans, Jabber se développe aussi bien du côté serveur que du côté client, et cela sur diverses plateformes (WindowsXP/98/2000, MacOS X, *BSD, ..., GNU/Linux). La maturité des différents projets, ainsi que l'utilisation grandissante de l'ensemble des outils à des tailles critiques, montrent que Jabber arrive à maturité. Ainsi, depuis fin 2002, l'IETF¹, chargée de la standardisation de la majorité des protocoles utilisés sur Internet, a créé un groupe visant à bâtir à partir de Jabber, le protocole XMPP². Ce protocole doit répondre à différentes problématiques posées par l'Instant Messaging³ comme les soucis d'interopérabilité dûs à des protocoles propriétaires tels que: ICQ, AIM, MSN ou Yahoo!Messenger. Jabber est donc une alternative Open Source à ces protocoles propriétaires, permettant de se libérer de leurs modèles centralisés. On notera que le projet est soutenu par des sociétés telles que IBM, HP, Hitachi ou France Telecom.

D'un point de vue technique, Jabber s'appuie sur un standard: XML. Cet outil de description des données, standard du W3C ⁴, est la technologie utilisée pour l'échange des données à l'intérieur du système Jabber. Et cela à différents niveaux: d'une part au niveau des échanges entre clients et serveurs, mais aussi au niveau de la configuration du serveur (chose relativement nouvelle en 2000). Jabber s'appuie donc sur une technologie extensive et viable à long terme, qui lui assure modularité et développement cohérent.

Comme nous allons le voir, Jabber possède des bases saines, aptes à faire de ce protocole un nouveau standard. Il est donc important de comprendre l'architecture de Jabber, et comment il peut s'intégrer aux technologies existantes, et comment il peut remplacer avantageusement certaines. Enfin, un tutoriel permettra de guider l'utilisateur intermédiaire vers la mise en place d'un serveur Jabber, chose naturelle, tout comme l'on installe un serveur HTTP ou SMTP. Ainsi tout au long de ce document, un analogie abusive entre les mécanismes d'acheminement des « EMails » et Jabber sera faite, afin de rendre le document plus compréhensible.

L'architecture actuelle de Jabber

Jabber est basé sur une architecture client/serveur où les serveurs sont interconnectés entre eux. Chaque client « discute » directement avec un serveur qui relaye ses messages via d'autres serveurs, tout comme cela se fait lorsqu'un Email est envoyé: il est d'abord reçu par le serveur SMTP du fournisseur d'accès qui se charge d'acheminer l'Email au serveur récupérant les messages du destinataire.

Schéma Général

Description des acteurs

Chaque utilisateur de Jabber possède un JID⁵ qui s'écrit tout comme une adresse email:

<nom_utilisateur>@<nom_domaine>

Tous les JID sont stockés dans un JUD⁶. Ce dernier peut être synchronisé ou non avec le JUD de Jabber.org qui est un annuaire public, ce qui permet à un autre utilisateur de vous trouver par rapport aux informations complémentaires demandées lors de votre inscription.

• Clients

• PC

• Assistant Personnel relié à un réseau

• Mobile

• Poste partagé par plusieurs utilisateurs

• Serveurs

• Système relié à Internet avec un serveur Jabber

• JUD: Jabber User Directory

• Local

• Global (hébergé par Jabber.org)

• Jabber Messaging

• One on One Chat

• Message

• Conference

• Privée

• Publique

Fonctionnement

Tout comme un client Email, le client Jabber effectue diverses opérations de base avec le serveur. D'un point de vue chronologique, il est possible de distinguer les étapes suivantes:

• Authentification avec le serveur local (sur la machine ou sur le réseau local)

• Demande d'informations sur les capacités du serveur

• Chargement des contacts de l'utilisateur

• Annonce de la présence (Online, Away, Busy, Invisible)

• Récupération de messages en attente

• ...

• < Envoi, réception de messages, changement de présence >

• ...

• Annonce de fin de présence

• Notification de fin de session au serveur

Le serveur gère les sessions et les messages du client. Lorsqu'un client essaye d'atteindre un utilisateur en dehors du serveur, ce dernier effectue la connexion pour le client et relaye son message. De même, c'est à travers lui que le client effectue les recherches de contacts. Le serveur se charge donc d'acheminer les requêtes des clients vers les entités y répondant. Il s'agit aussi d'une base de données, puisque la liste des contacts d'un client sont sauvegardés⁷, ainsi que les messages pouvant être reçus lorsque le client est déconnecté. Le serveur Jabber effectue donc le travail des serveurs SMTP et POP/IMAP dans le cadre des Emails.

Voilà ce qu'il est possible de dire d'un point de vue global sur le fonctionnement d'un serveur. L'objet de ce document n'est pas de rentrer dans les détails qui sont pourtant très intéressants. On se reportera donc à la documentation suivante: http://yvozin.free.fr/jabber/

Ajout de fonctionnalités par « transports »

Comme nous l'avons vu, Jabber est, de part sa conception et les technologies sur lesquelles il repose, modulaire et extensible. Ainsi le concept de transporteurs, permet d'étendre les fonctionnalités d'un serveur. Il s'agit de passerelles vers d'autres protocoles. A l'heure actuelle on peut citer ceux utilisés: ICQ/AIM, MSN, Yahoo, IRC, SMTP. Ainsi, grâce à ces passerelles, le serveur peut fournir au client de nouvelles capacités.

Ces transporteurs permettent aussi une migration aisée des utilisateurs utilisant les anciens protocoles propriétaires. C'est pourquoi, un nouvel utilisateur Jabber pourra joindre ses anciens contacts de manière transparente.

La continuité avec les anciens protocoles est donc assurée, et Jabber permet aussi d'accéder de manière unifiée à l'ensemble de ces ressources.

Les différents types de configurations

• Local

On obtient un serveur local en le rendant inaccessible depuis l'extérieur (écoute sur une interface spécifique/firewall) ou bien en lui donnant un nom qui ne se résout qu'à l'intérieur d'un réseau (par exemple avec le système de vues de BIND). En effet, si le nom du serveur est jabber.monreseau , le domaine « monreseau » n'étant pas valide sur internet, il sera impossible de s'y connecter depuis l'extérieur, et aucun message ne pourra être échangé entre vos utilisateurs et ceux d'autres serveurs sur Internet. (La communication avec d'autres serveurs locaux étant possible, tant que ceux-ci peuvent résoudre le nom de votre serveur)

• Privé

Dans ce type de configuration, le nom du serveur se résout sur Internet, mais vous cloisonnez les accès. Ainsi, il est possible de rendre un serveur accessible à l'extérieur uniquement pour les personnes enregistrées chez vous, tout en empêchant les autres de s'inscrire. Vos utilisateurs peuvent alors se connecter depuis n'importe où via Internet, tout en gardant leurs listes de contacts, ainsi que l'accès aux diverses passerelles présentes.

• Public

Votre serveur est ouvert et vous acceptez de servir de nouveaux clients. Ainsi, tout le monde pourra s'enregistrer chez vous et bénéficier par votre intermédiaire des passerelles que vous avez mises en place. Si vous désirez participer à l'effort de déploiement de Jabber, vous pouvez référencer votre site sur: http://www.jabber.org/user/publicservers.php

En résumé:

Quels sont les apports de Jabber ?

Les apports de Jabber pour l'utilisateur se déduisent naturellement de ce qui précède. Tout d'abord, Jabber permet une meilleur compréhension de l'échange de l'instant messaging, puisque l'identifiant d'un utilisateur est similaire à celui qu'il a pour ses Emails. La migration du système d'envoi d'emails, vers l'instant messaging est donc plus aisée. Ensuite, les utilisateurs déjà familiarisés avec les divers protocoles prioritaires, pourront migrer sans douleur vers Jabber, puisqu'à travers lui, ils pourront garder le contact avec leurs amis n'ayant pas migré.

En ce qui concerne l'administrateur ou l'entreprise hébergeant un serveur Jabber. Cette dernière assure donc elle-même l'acheminement des messages, tout en contrôlant l'accès aux services. Il est possible de définir les règles de sécurité et permettre un cryptage des messages échangés. Jabber étant évolutif, cette solution assure un développement durable au sein de l'entreprise, tout en garantissant l'indépendance du système d'information par rapport à des sociétés extérieures. Ainsi un réseau de serveurs Jabber peut s'avérer très utile, d'autant qu'une fois mis en place, son évolution sera souple.

Jabber peut donc apporter un gain de productivité puisqu'il permet de savoir si une personne est directement joignable ou non, et de la joindre si possible. Cette solution d'Instant Messaging est viable du fait que les clients sont stables et matures, mais aussi disponibles sur quasiment toutes les plateformes utilisées couramment en entreprise. C'est un outil global, fonctionnel, modulaire, évolutif et maîtrisé.

Tutoriel – Installation d'un serveur Jabber

Packages et versions

L'ensemble des informations qui suivent, sont relatives au serveur JabberD 1.4.2 et aux transports associés.

L'ensemble des « packages », nécessaires à une installation complète, peuvent être trouvés à l'adresse suivante:

http://jabberd.jabberstudio.org/

A titre indicatif, voici les versions exactes des outils employés lors du début de rédaction de ce document:

Installation

JabberD

Le serveur s'installe à partir des sources. Il peut être placé dans n'importe quel répertoire, mais dans un soucis de commodité, nous décompresserons l'archive contenant le serveur dans /usr/lib et nous renommerons le répertoire jabber-1.4.2 en jabber. Ainsi, toute l'arborescence relative à Jabber se trouvera donc dans /usr/lib/jabber .

Si les outils nécessaires à la compilation du serveur sont présents sur votre système, les étapes suivantes doivent vous permettre d'obtenir un binaire pour votre système. Toute erreur de dépendance⁸ doit logiquement survenir durant la 5ème étape:

1. cd /usr/lib

2. tar xzvf jabber-1.4.2.tar.gz

3. mv jabber-1.4.2 jabber

4. cd jabber

5. ./configure

6. make

Vous devez à présent avoir le binaire suivant: ./jabberd/jabberd

Transports

Les transports sont fournis de manière générale sous la forme d'archives contenant les sources des passerelles.

Il est impossible de décrire une démarche générale permettant d'aboutir à une installation effective pour chacun des transports, puisque les procédures dépendent de chacun des transports.

Néanmoins, on suivra l'organisation suivante:

• toutes les sources seront décompressées dans /usr/lib/jabber

• les binaires (librairies dynamiques .so) et les fichiers de configuration spécifiques seront placés dans /usr/lib/jabber/transports

Le plus souvent, la compilation d'une passerelle nécessite l'indication du répertoire où se situe le serveur jabberd, c'est à dire /usr/lib/jabber/jabberd

Exemple d'installation de ICQv7-t:

La compilation de cette passerelle requiert la présence de la librairie libicq2000. L'installation de cette librairie n'est pas décrite ici, mais elle s'effectue de manière classique, sans aucun problème.

Notez bien que cette passerelle a la particularité d'être scindée en 2 (ce qui n'est pas le cas des autres passerelles en général) pour des raisons de licences.

Les étapes suivantes permettent d'obtenir les binaires relatifs à la passerelle ICQ:

• cd /usr/lib/jabber

• tar xzvf icqv7-t-0.3.0pre2.tar.gz

• cd icqv7-t-0.3.0pre2

• ./configure –with-jabberd=/usr/lib/jabber/jabberd⁹

• make

• cp ./icqv7ext ./jabberd/icqv7t.so /usr/lib/jabber/transports/

Configuration

JabberD et les services de base

La configuration fournie par défaut avec le serveur est tout à fait convenable dans la majorité des cas. Il est néanmoins nécessaire de l'adapter. Ceci est relativement facile puisqu'il suffit de parcourir le fichier de configuration jabber.xml où des commentaires vous permettent de comprendre à quoi se réfère chaque partie du fichier XML.

Ainsi, la tâche consiste à adapter le fichier de configuration suivant la type de serveur que vous avez choisi.

La configuration se fera pas à pas:

<host><jabberd:cmdline flag="h">localhost</jabberd:cmdline></host>

Ceci définit le nom du serveur. Il convient de remplacer localhost par la valeur adéquate. Dans le cas d'un serveur local, le nom est celui de votre machine, dans les autres cas le nom entier de votre machine doit être spécifié: localhost.localdomain par exemple ou bien la racine de votre domaine, si elle pointe vers votre machine: localdomain.

<admin>

<read>support@localhost</read>

En remplaçant support@localhost par le nom d'un utilisateur @ votre nom de serveur jabber, vous autorisez cette personne à lire les messages adressés au serveur. C'est à dire ceux pour l'administrateur. C'est notamment cette personne qui sera avertie de l'inscription d'un nouveau membre.

<write>admin@localhost</write>

Ceci définit la personne pouvant envoyer un message qui sera diffusé à tous les utilisateurs du serveur. Il s'agit généralement de l'administrateur.

<reply>

<subject>Auto Reply</subject>

<body>This is a special administrative address. Your

message was received and forwarded to server administrators.

</body>

</reply>

</admin>

<update><jabberd:cmdline flag="h"> localhost

</jabberd:cmdline></update>

Ceci permet d'être averti d'une mise à jour du serveur. Si votre serveur est local, il est préférable de commenter cette ligne en ajoutant <!-- avant et --> après. Dans les autres cas, si cette fonctionnalité vous intéresse, il suffit de remplacer localhost par le nom de votre serveur Jabber.

<browse>

Cette section permet de définir les passerelles et les services (tels que JUD) accessibles depuis votre serveur. Chaque service ou passerelle doit faire l'objet d'une section <service> ... </service> plus loin dans le fichier de configuration.

<service type="jud" jid="users.jabber.org" name="Jabber User

Directory">

<ns>jabber:iq:search</ns>

<ns>jabber:iq:register</ns>

</service>

Par défaut, le JUD est celui de Jabber.org, néanmoins, si vous désirez un serveur local, dont les utilisateurs ne sont pas visibles de l'extérieur, il sera nécessaire de remplacer le jid par une adresse locale du type: users.localdomain

L'installation de services relatifs aux passerelles est détaillé dans la section suivante. Mais voici les exemples normalement fournis par défaut dans le fichier de configuration.

<conference type="private" jid="conference.localhost" name="Private Conferencing"/>

<service type="aim" jid="aim.localhost" name="AIM Transport">

<ns>jabber:iq:gateway</ns>

<ns>jabber:iq:register</ns>

</service>

<service type="yahoo" jid="yahoo.localhost" name="Yahoo! Transport">

Les 2 lignes qui suivent, définissent les fonctionnalités par les services, et donc ici, les passerelles.

<ns>jabber:iq:gateway</ns>

<ns>jabber:iq:register</ns>

</service>

</browse>

<load main="jsm">

Cette section définit l'ensemble des modules pouvant être utilisés par le gestionnaire de session: JSM.

<jsm>./jsm/jsm.so</jsm>

...

<mod_presence>./jsm/jsm.so</mod_presence>

<mod_auth_plain>./jsm/jsm.so</mod_auth_plain>

<mod_auth_digest>./jsm/jsm.so</mod_auth_digest>

<mod_auth_0k>./jsm/jsm.so</mod_auth_0k>

<mod_log>./jsm/jsm.so</mod_log>

<mod_register>./jsm/jsm.so</mod_register>

Commentez cette ligne si vous ne voulez pas qu'un nouvel utilisateur puisse s'inscrire sur votre serveur.

<mod_xml>./jsm/jsm.so</mod_xml>

</load>

<xdb id="xdb">

Cette section est relativement anodine pour l'instant, mais elle définit la manière dont les informations relatives aux utilisateurs sont stockées. Ici tout est enresgitré sous forme de fichiers dans le répertoire spool. Elles pourraient aussi l'être dans une base de données.

<host/>

<load>

<xdb_file>./xdb_file/xdb_file.so</xdb_file>

</load>

<xdb_file xmlns="jabber:config:xdb_file">

<spool><jabberd:cmdline flag='s'> ./spool

</jabberd:cmdline></spool>

</xdb_file>

</xdb>

<service id="c2s">

Il s'agit ici de déterminer comment la connexion entre le client et le serveur va s'effectuer.

<load>

<pthsock_client>./pthsock/pthsock_client.so</pthsock_client>

</load>

<pthcsock xmlns='jabber:config:pth-csock'>

<authtime/>

<karma>

On définit les règles de protection, en limitant le nombre de connexions successives. Si les limites sont dépassées, alors le service ne répond plus pendant un certain temps.

<init>10</init>

<max>10</max>

<inc>1</inc>

<dec>1</dec>

<penalty>-6</penalty>

<restore>10</restore>

</karma>

<ip port="5222"/>

Le port sur lequel nous allons écouter. Il est possible de restreindre l'écoute à une ou plusieurs interfaces suivant leur adresse IP: <ip port="5222">127.0.0.1</ip>

<ssl port='5223'>127.0.0.1</ssl>

<ssl port='5224'>192.168.1.100</ssl>

Ici nous définissons les ports sur lesquels s'effectueront les connexions sécurisées via SSL.

Pour que cela soit effectif, il est nécessaire que le serveur ait été compilé avec le support SSL.

</pthcsock>

</service>

<io>

<karma>

Cette limitation s'applique à l'ensemble du trafic au niveau du serveur, quelques soient les passerelles utilisées ou services.

<heartbeat>2</heartbeat>

<init>10</init>

<max>10</max>

<inc>1</inc>

<dec>1</dec>

<penalty>-6</penalty>

<restore>10</restore>

</karma>

Configuration d'une passerelle

Il existe 2 manière de mettre en service les passerelles:

1. les passerelles sont gérées par un seul et même processus

2. un processus prend en charge une passerelle pour le serveur

Dans le premier cas, un seul processus jabberd prend en charge les interactions avec les autres protocoles. L'avantage réside dans le fait qu'il ne soit pas nécessaire de gérer plusieurs configurations différentes, mais l'inconvénient majeur provient du fait suivant: si le composant logiciel chargé de gérer une passerelle « crash » alors c'est tout le serveur qui est arrêté.

Dans le deuxième cas, un processus est lancé et il ouvre un port de communication pour d'autres serveurs Jabber gérant une passerelle spécifique. Ainsi si le serveur chargé de gérer une passerelle tombe, le serveur principal, lui, continue à tourner. Cela permet aussi d'effectuer des mises à jour des passerelles sans obliger l'ensemble des utilisateurs présents à se reconnecter.

Dans les deux types de configuration, le fichier de configuration XML du serveur principal doit être enrichi des informations suivantes:

• section <service> dans la section <browse>

<service type= « nom du service » jid="nom du service.localhost.localdomain" name="Passerelle vers Nom du Service">

<ns>jabber:iq:register</ns>

<ns>jabber:iq:gateway</ns>

<ns>fonctionnalités de la passerelle</n>

</service>

• section <service>

<service id='nom du service.localhost.localdomain'>

<icqtrans xmlns='jabber:config:icqtrans'>

...

Configuration spécifique à la passerelle

...

</service>

Cette section va être différente suivant la configuration des passerelles que vous avez choisi. Dans la cas d'une configuration à plusieurs serveurs, il sera nécessaire de créer un fichier de configuration spécifique. Le service apparaîtra dans le fichier de configuration principal comme un lien (link) avec un port attribué.

Exemple:

• dans jabber.xml (serveur principal)

<service id="yahoo-linker">

<host>yahoo.localdomain</host>

<accept>

<ip>127.0.0.1</ip>

<port>5051</port>

<secret>secretpass</secret>

</accept>

</service>

• dans jabber-yahoo.xml (serveur pour la passerelle)

<service id="yahoo-linker">

<connect>

<ip>127.0.0.1</ip>

<port>5051</port>

<secret>secretpass</secret>

</connect>

<uplink/>

Ceci définit le serveur, comme celui qui sera l'esclave du serveur principal.

</service>

<service id="yahoo.localdomain">

<load><yahoo_transport>/usr/lib/jabber/transports/yahoo-transport.so</yahoo_transport></load>

<config xmlns="jabber:config:yahoo">

<vCard>

<NAME>Yahoo Transport</NAME>

</vCard>

<server>scs.yahoo.com</server>

<port>5050</port>

<charmap>CP1252</charmap>

</config>

</service>

A peu de choses près, ce que l'on aurait trouvé dans une configuration à processus unique.

La configuration d'une passerelle dépendant de chaque protocole, il est quasiment impossible de proposer un schéma type de configuration. Il s'agit donc de se référer à la documentation fournie avec la passerelle. Dans la majorité des cas, un exemple de configuration est fourni pour les 2 types d'approches: uni-serveur, multi-serveurs. Vous noterez qu'il est possible de faire tourner un serveur dédié à une passerelle sur une machine qui servira un ensemble d'autres serveurs principaux.

D'un point de vue réseau, les ports de communication entre les serveurs jabber se résument aux ports 5222 et 5223 (pour SSL). Néanmoins, les passerelles vers les autres protocoles en requièrent d'autres. A l'aide de la configuration multi-serveurs, il est possible de placer une passerelle en dehors d'une zone protégée et d'acheminer toutes les données relatives à un protocole particulier via un seul port. De ce fait, les données relatives aux utilisateurs restent dans la zone sécurisée.

Conclusion

Le présent document a tenté de mettre en avant les apports de jabber tant d'un point de vue technique que pour l'utilisateur et l'administrateur. A travers un tutoriel, il a été montré comment pouvait être configuré un ou plusieurs serveurs et différents cas d'utilisation, notamment suivant une politique de sécurité et de qualité définie.

Jabber ou XMPP est un protocole ouvert sur lequel des solutions d' « instant messaging » ont été et sont développées. Elles sont tout particulièrement modulaires, robustes et évolutives. Elles mettent à disposition de tous une infrastructure pouvant être comparée à celle utilisée pour les Emails, c'est à dire une maîtrise locale (indépendance vis à vis d'acteurs tiers), une sécurisation accrue (cryptage et mécanismes assurant une meilleure sécurité du réseau) et en particulier une base solide permettant le développement d'une réelle plateforme d'échange de messages globale. Tous ces apports sont dès à présent accessibles via des serveurs implémentant cette technologie, ainsi que des clients. Dans les 2 cas, la maturité des logiciels proposés permet une utilisation quotidienne et sûre.