Jabber/XMPP

Oscar Lage Serrano oscar@[Link]

15 de Junio de 2005

Esta obra est publicada bajo la licencia de Creative Commons: Reconocimiento-NoComercial-CompartirIgual 2.1 Espaa [Link]

Indice

La Mensajera Instantnea (Instant Messaging) y el protocolo Jabber/XMPP ........ 1 Fundamentos tcnicos de Jabber/XMPP .................................................................. 7 2.1. Modelo de mensajera....................................................................................... 7 2.1.1. Ventajas .................................................................................................... 8 2.1.2. Inconvenientes .......................................................................................... 9 2.1.3. Comunicaciones S2S (Server to Server) ................................................ 10 2.1.4. Encaminamiento de los paquetes Jabber/XMPP .................................... 10 2.2. Ejemplo de una sesin Jabber/XMPP............................................................. 11 3. Message protocol.................................................................................................... 15 4. Presence protocol.................................................................................................... 20 5. Groupchat protocol ................................................................................................. 24 6. Info/Query protocol ................................................................................................ 27 6.1. Registration protocol (jabber:iq:register) ....................................................... 31 6.2. Authentication protocol (jabber:iq:auth) ........................................................ 35 6.2.1. Anonymous Authentication.................................................................... 37 6.2.2. Plain Authentication ............................................................................... 37 6.2.3. Digest Authentication ............................................................................. 38 6.2.4. Zero-knowledge Authentication ............................................................. 38 6.3. Roster Protocol (jabber:iq:roster) ................................................................... 41 6.3.1. Roster reset ............................................................................................. 43 6.3.2. Roster update .......................................................................................... 44 6.3.3. Roster push ............................................................................................. 44 7. Autentificacin SASL ............................................................................................ 46 8. Comunicacin Server-to-Server (jabber:server)..................................................... 51 8.1. Dialback authentication .................................................................................. 52 9. Transporte entre Jabber/XMPP y otros servidores de MI ...................................... 55 10. Chatbots .............................................................................................................. 56 11. Jabber/XMPP como middleware ........................................................................ 57 12. Sitios de inters................................................................................................... 58 13. Agradecimientos................................................................................................. 59

1. 2.

1. La Mensajera Instantnea (Instant Messaging) y el protocolo Jabber/XMPP

Para poder hablar de Jabber/XMPP primero deberamos aclarar concepto de Mensajera Instantnea, ya que Jabber/XMPP es un protocolo Mensajera Instantnea. Adems en un futuro prximo la MI se convertir uno de los pilares fundamentales de la red empresarial, como ya lo es hoy da el correo electrnico. el de en en

Los Chat, ya sean privados o en grupo, son el origen de la MI. Pero podemos buscar sistemas anteriores como son el clsico comando talk de UNIX, que permita a los usuarios de este sistema hablar a travs de la red muchos aos antes de que la MI entrara en accin. Otro precursor de estos sistemas es el ya clsico IRC (Internet Relay Chat) que permita hablar en grupos de usuarios a travs de Internet. La gran innovacin de la MI es el agrupamiento de todos estos sistemas en uno solo. Adems poco a poco van introduciendo mejoras como son la presencia, transferencia de ficheros e incluso conversaciones con voz y video. Adems nos ofrecen un nombre nico en la red para poder hablar directamente con quien t quieras, porque sabes que detrs de ese nombre siempre va a estar la misma persona. Esto no ocurra en los antiguos Chat de Internet, en los que aunque la gente intentaba poner siempre el mismo nombre o apodo (Nickname) para entrar en una conversacin, esto no era siempre posible, porque cualquiera poda usurpar su identidad conectndose con su apodo habitual. Hoy en da la MI nos ofrece un nombre nico en la red, y nos permite identificarnos bajo una contrasea para que nadie pueda pasarse por nosotros. Gracias a esta innovacin podemos agregar nuestros contactos en el sistema de MI para poder hablar con ellos sin necesidad de acordarnos de sus identificadores. Esto a su vez conlleva a que, gracias al protocolo de presencia, podremos conocer en cada momento el estado de nuestro contacto, es decir, cada usuario podr estar conectado o no. De estar conectado, podr adoptar diferentes estados como pueden ser, en lnea, ocupado, ausente as todas las personas que le tengan agregado como contacto podrn ver siempre que lo deseen su estado. Adems la MI no sirve nicamente para la comunicacin entre personas, tambin permite la comunicacin entre ordenadores, as mquinas autnomas como bien pueden ser estaciones meteorolgicas pueden comunicarse con un ordenador central para comunicar un cambio en su estado, o el ordenador central ir recorriendo todas las estaciones y preguntndoles por sus variables de temperatura, presin Esto permite un dilogo entre un ordenador central y una estacin meteorolgica, y as podemos encontrar muchos ms usos en campos como la robtica, sistemas expertos de Inteligencia Artificial, B2B, juegos, domtica

Adems la MI ha entrado con fuerza en el servicio postventa de muchas grandes empresas ya que permite al cliente comunicarse con el servicio postventa de su proveedor sin necesidad de gastos telefnicos, y de una forma fluida y cmoda. Jabber/XMPP podra ser usado como ncleo de stos y otros sistemas. Adems Jabber/XMPP tiene muchas ventajas con respecto a sus competidores, como pueden ser: o Jabber/XMPP es un protocolo totalmente abierto que permite a cualquier desarrollador implementar Jabber/XMPP sin ningn coste. o El intercambio de mensajes se realiza en formato XML. o Es capaz, mediante pasarelas, de comunicarnos con otros sistemas de MI. El valor de un sistema de comunicaciones se incrementa con el nmero de personas con las que te puedes comunicar. o Simplifica las responsabilidades del cliente a lo ms mnimo. o Ninguna organizacin, grupo o servicio controla el sistema.

Si el estndar abierto de Jabber/XMPP es una de sus grandes ventajas, podramos considerar el sistema de mensajes basados en XML como otra gran ventaja. XML es un estndar de World Wide Web Consortium (W3C) que define una forma estndar y genrica de formato de datos para documentos. Su gran ventaja es su simplicidad y adaptabilidad a las comunicaciones entre seres humanos y ordenadores. Todos los mensajes basados en el protocolo Jabber/XMPP sern fragmentos de XML, que pueden considerarse partes del gran documento que sera la comunicacin total del cliente y el servidor. Por ejemplo un mensaje que ira dirigido a oscar@[Link] quedara as:
<message to=oscar@[Link]> <subject>Qu tal ests?</subject> <body>Dime si puedes quedar esta noche</body> </message>

Como puede verse, cualquier persona que no haya ledo nunca un fragmento de XML podra adivinar perfectamente el destinatario, el ttulo y el cuerpo de este mensaje. Por ello es por lo que XML se est haciendo tan famoso en los ltimos tiempos. Adems es abierto, simple, flexible y portable. Es decir, podemos crear nuestros propios documentos XML, con nuestros formatos y reglas. Adems permite la comunicacin entre diferentes lenguajes de programacin, as cualquier cliente Jabber/XMPP que est desarrollado en Java podra comunicarse perfectamente con cualquier servidor escrito en c/c++, ya que lo que intercambiaran siempre seran mensajes XML. El protocolo Jabber/XMPP sigue la tan conocida arquitectura cliente/servidor. Los clientes Jabber/XMPP nicamente se comunican con el servidor Jabber/XMPP de su dominio, que es quien les ofrece el servicio.

Los dominios Jabber/XMPP rompen el mundo de la MI en zonas separadas de control, cada una soportada y administrada por separado por el servidor o grupo de servidores del dominio al que pertenece cada usuario. Esto contrasta con los dems servicios de MI que usan un servidor, o un grupo de servidores centralizados para toda la comunicacin del sistema de MI. En Jabber/XMPP los mensajes pasan del cliente emisor al servidor de ste, y el servidor del dominio los enva al servidor del dominio del usuario destino para as ser enviados al cliente destinatario del mensaje. En los sistemas cliente/servidor, el cliente muestra informacin al usuario final y maneja sus peticiones, las peticiones del cliente son enviadas al servidor que ofrecer unos determinados servicios. En Jabber/XMPP esta arquitectura es seguida para crear clientes simples, ya que as la mayora del procesamiento de la lgica del sistema de MI es llevada a cabo por el servidor. Esto hace ms fcil la programacin e implementacin de clientes de MI Jabber/XMPP , y la complejidad del cliente depender de las necesidades del cliente. As para crear un cliente de MI de Jabber/XMPP que simplemente enve y reciba mensajes slo habr que implementar esa pequea parte del protocolo, y la mayor parte de la programacin del cliente estar entonces en el desarrollo de la interfaz del mismo. Adems gracias a la arquitectura cliente/servidor nos ofrece la excelente oportunidad de implementar un control centralizado de los dominios Jabber/XMPP y la oportunidad de controlar la calidad del servicio. Esto es especialmente interesante para el mundo empresarial, en el que muchas empresas necesitan de la comunicacin de la MI, pero tambin necesitan de un control de las comunicaciones de sus empleados. Tal y como el actual sistema de correo electrnico permite tener diferentes servidores de correo administrados en diferentes dominios, los servidores de Jabber/XMPP administran sus dominios Jabber/XMPP. Adems, al igual que el correo electrnico, los dominios Jabber/XMPP son definidos por el dominio de nombres de Internet al que pertenecen. As pues, el servidor de Jabber/XMPP del dominio [Link] deber manejar todos los mensajes de entrada y salida de los usuarios de su dominio. Las direcciones Jabber/XMPP, conocidas como Jabber ID, especifican el dominio del usuario a partir del carcter @ tal y como lo hacen las direcciones de correo electrnico. Con la creacin de la arquitectura de servidores Jabber/XMPP, se limita a cada servidor a tratar nicamente con sus clientes Jabber/XMPP y con otros servidores Jabber/XMPP. As, si se incorpora un servidor Jabber/XMPP a una red empresarial, y se instalan clientes Jabber/XMPP en todos los puestos de trabajo, la calidad del servicio y el tiempo de respuesta de los mensajes instantneos dentro de la red empresarial, depender nicamente de la carga que stos usuarios ejerzan sobre el servidor de Jabber/XMPP empresarial, y no como en otros sistemas de MI en el que la calidad del servicio de MI depender de todas las transacciones que se realicen sobre el servidor principal del

sistema. Adems si a la empresa no le interesa implementar o abrir el puente hacia otros servidores Jabber/XMPP, sus empleados nicamente podrn comunicarse entre ellos, y no podrn comunicarse con otros usuarios de otros dominios Jabber/XMPP. Esta prctica es la que les lleva a muchas empresas a la instalacin de un servidor Jabber/XMPP en su red empresarial, ya que la MI es muy til para las empresas, pero si los trabajadores se dedican a hablar con amigos o familiares los inconvenientes superan a las ventajas. De esta forma las empresas slo encuentran beneficios a la hora de implantar un servidor de MI Jabber/XMPP. Adems de toda la arquitectura de dominios, Jabber/XMPP tambin tiene otras particularidades como puede ser la distincin de un usuario (user) y una conexin de ste (resource). Cada usuario de Jabber/XMPP es una terminacin lgica de mensajes en la red, que representar a una persona o una cuenta de usuario. Sin embargo, al contrario de otros sistemas de MI, en Jabber/XMPP un usuario puede estar conectado simultneamente a su servidor de dominio de Jabber/XMPP desde diferentes clientes pero con su nico identificador Jabber/XMPP (Jabber ID). Esto es til, por ejemplo, si un usuario se conecta desde su trabajo para recibir sus mensajes, pero cuando el est fuera de su lugar de trabajo el podra conectarse desde el telfono para seguir hablando, aunque el ordenador del trabajo siga conectado con su cuenta. El usuario podr seguir enviando y recibiendo mensajes desde su telfono, y cuando decida dejar de hacerlo se desconectar, por lo que todos los siguientes mensajes seguirn llegando al ordenador del trabajo para que pueda ver lo que le han escrito en el tiempo en el que no ha estado conectado desde el telfono, e incluso podr enviar mensajes a su conexin del trabajo para recordar algo que deba hacer cuando vuelva al trabajo, ya que el mensaje quedar en el ordenador del trabajo. Esto es posible gracias a los resources de Jabber/XMPP, o diferentes conexiones, que representan un particular punto final de la conexin. En la mayora de los casos se envan paquetes a los usuarios, y stos son recibidos por la conexin actual del cliente. El servidor de Jabber/XMPP debe de administrar el reenvo de estos paquetes a la conexin ms apropiada del usuario en cada momento. Si por ejemplo yo quiero enviar un mensaje al usuario oscar que pertenece al dominio [Link], lo envo y el servidor recibe el paquete. El servidor mirar si el usuario oscar se encuentra conectado, si no es as almacenar el paquete para envirselo cuando se conecte. Si el usuario tiene una conexin abierta, el paquete le ser enviado inmediatamente, pero si tiene varias, el servidor deber decidir a cul de las conexiones reenviar el paquete, es decir, cul de las conexiones es la principal o actual conexin de ese cliente para que pueda recibir el mensaje lo antes posible. Imaginemos que yo tengo dos clientes Jabber/XMPP conectados con mi Jabber ID, uno en el mvil y otro en el ordenador del trabajo. Los clientes usarn diferentes nombres de conexin: mvil y trabajo. El servidor detectar esta conexin, y determinar que mvil es mi conexin por defecto si est disponible, y reenviar el paquete a esa direccin.

Cada usuario puede crear una lista de las conexiones y priorizarlas. Adems podr comunicarse entre sus conexiones ya que sabe que la direccin de la conexin del trabajo ser:oscar@[Link]/trabajo mientras que la del mvil ser: oscar@[Link]/mvil. Adems el protocolo nos permite enviar paquetes a un servidor en concreto, estos paquetes no irn destinados a un usuario del servidor, si no al servidor. Por ejemplo podramos enviar un mensaje a [Link] directamente, como lo haremos cada vez que deseamos autentificarnos en el servidor, cambiar nuestros datos o nuestros contactos. Adems esto es usado por los servidores de cada dominio para reenviar paquetes de sus usuarios a usuarios de otros dominios. Adems es posible enviar paquetes a una conexin del servidor en concreto: [Link]/admin. La compacta y sencilla estructura de los Jabber ID los hace fciles de memorizar y usar. La nica pega de este formato es la fcil confusin entre Jabber IDs y cuentas de correo electrnico. Los administradores de dominios Jabber/XMPP pueden simplificar esto utilizando los mismos nombres de Jabber ID y de e-mail para sus usuarios. Jabber/XMPP como ya hemos dicho contiene el protocolo de presencia como la mayora de sistemas de MI de hoy en da. Muchas veces un simple conectado/desconectado es suficiente. Pero Jabber/XMPP permite a los usuarios configurar otros estados como sal a comer o me he ido de paseo. Estos estados permiten a los usuarios interactuar y expresarse de una forma mucho ms personal. Jabber/XMPP adems permite crear listas de contactos (rosters), que permiten al usuario tener una lista de otros usuarios y conocer su estado actual. Los contactos en Jabber/XMPP son guardados por el servidor de dominio Jabber/XMPP del cliente, para que as estn siempre disponibles desde donde quiera que se conecte el usuario. Adems permite confirmar o cancelar una suscripcin de otro usuario. Esto permite proteger la privacidad del usuario y determinar quin tiene permiso para conocer el estado de cada usuario. El sistema de presencia de Jabber/XMPP es tan flexible que permite la aplicacin del mismo para su uso en aplicaciones en las que hara falta simplemente un servicio de presencia. Por ejemplo, con un detector de movimientos de una alarma del hogar un usuario podra estar charlando con sus amigos y tener como contacto a ese detector, que estara unido a un ordenador conectado como un usuarios Jabber/XMPP, as podra saber si hay alguien en su jardn. Podran as conectarse un montn de sensores de una alarma y conocer el estado de cada puerta y ventana de la casa simplemente unindolos todos a un ordenador conectado a un cliente de presencia Jabber/XMPP. As podramos conocer el estado de la ventana de nuestra habitacin desde el trabajo.

Pero Jabber/XMPP tambin tiene sus problemas debido a que es un protocolo hoy por hoy inmaduro, y en pleno desarrollo. La mayora de la documentacin oficial del estndar Jabber/XMPP est incompleta o sin actualizar y la nica respuesta a las preguntas sobre el protocolo es probar el comportamiento del servidor de referencia de Jabber/XMPP. Adems el protocolo sufre de ineficiencias directamente relacionadas con su naturaleza XML, ya que los formatos binarios de datos reducen el ancho de banda necesario para su transporte por la red, as como su procesamiento tanto en el cliente como en el servidor. Adems no disponen de la deteccin de errores y correccin. Otro problema de Jabber/XMPP es que al haber nacido tras la popularizacin del MSN Messenger y de otros sistemas de MI no consigue arrastrar a la gente hacia l. Por ello se est realizando ingeniera inversa con los protocolos de stos proveedores de MI para as poder crear puentes entre Jabber/XMPP y todos los dems sistemas, as desde Jabber/XMPP los usuarios podran conectarse con todos los dems usuarios de otros sistemas, as esto no sera un problema a la hora de cambiarse a Jabber/XMPP.

2. Fundamentos tcnicos de Jabber/XMPP

Primero vamos a analizar el modelo de mensajera de Jabber/XMPP para ms adelante centrarnos en los tres protocolos fundamentales de Jabber/XMPP: message, presence e info/query.

2.1.

Modelo de mensajera

Es importante entender el modelo de mensajera de Jabber/XMPP antes de que un programador comience a desarrollar software que implemente el protocolo Jabber/XMPP. Primero hay que tener claro los participantes bsicos de una conexin Jabber/XMPP como son el servidor, el cliente, la conexin y el paquete. El servidor Jabber/XMPP participa en todas las comunicaciones Jabber/XMPP. Su principal responsabilidad es la de proveer de servicios Jabber/XMPP a los clientes de su dominio como pueden ser la redireccin de sus paquetes y la gestin de sus cuentas de usuario. El cliente Jabber/XMPP es quien interacta directamente con el usuario. Es el programa que muestra las respuestas del servidor y que recoge las peticiones del cliente y las enva al servidor para que las trate. Normalmente mensajes que el usuario quiere que lleguen a otro usuario y que el servidor deber localizar al otro usuario y hacerle llegar el paquete. La conexin es la realizada entre el cliente y el servidor, por la que viajarn los paquetes XML. Por ltimo, pero los ms importantes, los paquetes son las peticiones, mensajes, etc. que envan o reciben los usuarios, en forma de fragmentos de XML correctamente formados. El protocolo Jabber/XMPP es quien especifica el formato de estos paquetes. El servidor Jabber/XMPP, como todo servidor, es arrancado en un ordenador y se mantiene esperando conexiones de usuarios en un puerto. El estndar de Jabber/XMPP establece el puerto 5222 como el puerto estndar de los servidores Jabber/XMPP y el 5223 era usado en antes de SASL para conexiones cliente/servidor SSL seguras. Se pueden utilizar otros puertos, pero la mayora de los clientes Jabber/XMPP intentarn conectarse por defecto a estos dos puertos, por lo que debern ser reconfigurados para que se conecten a puertos alternativos. El cliente Jabber/XMPP comienza un flujo stream mandando la etiqueta XML <stream:stream> al servidor, esto representa el inicio de una sesin del cliente con el servidor. Cuando un servidor Jabber/XMPP acepta una conexin de un cliente responder con <stream:stream> para confirmar el inicio de la 7

sesin. Si hubiera un error en la sesin se enviara la etiqueta <stream:error> explicando el problema y cerrando la conexin por parte del servidor. Una vez que se ha establecido el flujo entre el cliente y el servidor pueden enviarse paquetes de acuerdo con los mltiples protocolos de Jabber/XMPP. En la mayora de los casos el servidor slo le dejar al cliente enviar unos pocos tipos de mensajes hasta que se autentifique, entre ellos como es normal los paquetes de autentificacin. La autentificacin permite al servidor verificar que el cliente es quien dice ser para poder actuar bajo el Jabber ID bajo el que se autentifica y enviar y recibir mensajes. El estndar de Jabber/XMPP no especifica el conjunto de protocolos disponibles para un usuario sin autentificar, pero como mnimo es normal que los usuarios puedan utilizar los protocolos de autentificacin y registro. Tanto el servidor como el cliente pueden cerrar el flujo de datos en cualquier momento enviando una etiqueta de cierre </stream:stream>. En ese momento, cada uno podr cerrar la conexin y terminar la sesin Jabber/XMPP. Es conveniente dejar a la otra entidad terminar de enviar un paquete que est en curso antes de cerrar la conexin. Tal y como hemos explicado esta sera una conexin tpica de Jabber/XMPP: o Conectarse con el puerto 5222 del servidor. o Enviar una etiqueta de sesin abierta <session:session>. o Esperar la respuesta del servidor <session:session>. o Usar el protocolo de autentificacin o para iniciar con su Jabber ID. o Enviar y recibir paquetes de acuerdo a los protocolos Jabber/XMPP. o Enviar la etiqueta de cierre </session:session> para terminar la sesin. o Cerrar la conexin. Esta simple conexin cliente/servidor tiene sus ventajas e inconvenientes.

2.1.1.

Ventajas

El modelo cliente/servidor distribuido de Jabber/XMPP tiene muchas ventajas. Una de las ms importantes es el uso de un modelo simple y conocido por todos los desarrolladores de software para las comunicaciones de red. El correo electrnico por ejemplo utiliza esta misma arquitectura de conexin. Este tipo de arquitectura slo permite dos tipos de escenarios,

cliente/servidor y servidor/servidor. Para todos los servidores que no tengan implementados los mecanismos de comunicacin entre servidores, slo se dar la primera situacin. La seguridad y privacidad de los clientes es muy buena, debido en gran medida a que cada cliente slo trata con su servidor, as los dems usuarios no tendrn ninguna referencia de dnde est ubicado realmente el cliente dentro de la red, lo nico que conocern es su Jabber ID, y la direccin del servidor al que ese cliente se conecta. Adems el cliente nunca aceptar conexiones como es el caso del servidor. Esto aumenta realmente la seguridad con respecto a las conexiones punto a punto que se realizan en otros tipos de clientes como Gnutella. El modelo de clientes ligeros beneficia a los desarrolladores de clientes que pueden desarrollar clientes con costes ms bajos y econmicos. Como consecuencia el desarrollador podr centrarse en aspectos importantes de cara al cliente como son la interfaz e integracin con otras aplicaciones, as como un fcil mantenimiento del cliente. Esta arquitectura permite al servidor del dominio centralizar el control de Jabber/XMPP, se pueden crear polticas de seguridad y aplicarlas sin tener que modificar los clientes o tener que controlar conexiones directas entre los clientes, ya que como se ha dicho todo el trfico pasa por el servidor. As, por ejemplo, se podran limitar el ancho de banda a ciertos clientes en ciertas horas, se podran denegar el envo de archivos en horas punta de la red empresarial, dar acceso a los clientes a comunicarse con ciertos dominios Jabber/XMPP las posibilidades en este campo son infinitas, y siempre habra que configurar nicamente el servidor.

2.1.2.

Inconvenientes

Como todo, la arquitectura cliente/servidor tambin tiene sus inconvenientes. Como la privacidad de cara a alguien que tenga acceso al servidor, ya que en l se almacenarn todos los mensajes que se reciban para las cuentas Jabber ID de los usuarios que no estn conectados. Pero los usuarios de Jabber/XMPP no estn tampoco a merced del servidor Jabber/XMPP, se pueden enviar mensajes codificados dentro de un mensaje de Jabber/XMPP tradicional. Los algoritmos de cifrado habituales pueden proteger los mensajes de los usuarios ante los curiosos. Otro gran problema de la arquitectura cliente/servidor es que si en la red empresarial slo existe un servidor de Jabber/XMPP y ste permanece inactivo durante un tiempo, los clientes no podrn comunicarse entre ellos. Este problema tiene una fcil solucin que es la instalacin de un grupo de servidores de Jabber/XMPP. Adems de la gran seguridad de las conexiones cliente/servidor, en las que otro cliente nunca puede averiguar tu direccin, esto tiene tambin su gran inconveniente. Conlleva a un cuello de botella que slo se podr ir

solucionando ampliando el servidor de Jabber/XMPP, o aadiendo nuevos servidores, y ampliando el ancho de banda de las conexiones con el servidor.

2.1.3.

Comunicaciones S2S (Server to Server)

Jabber/XMPP permite la instalacin de varios dominios de Jabber/XMPP, as como la comunicacin entre el servidor responsable de cada dominio con el resto de servidores. Los paquetes enviados por los clientes emisores son enviados por el servidor de su dominio al servidor del dominio del destinatario de los paquetes, y ste a su vez se los enva a los clientes destinatarios. Esta comunicacin entre servidores se denomina Server-to-Server (S2S). El protocolo S2S es esencialmente una copia del protocolo de los clientes, la conexin y el inicio del flujo de datos tambin se realiza enviando un stream de inicio abierto. El servidor emisor actuar como cliente en representacin de sus clientes enviando los mensajes de stos a los servidores destinatarios. Dividiendo la red Jabber/XMPP en diferentes dominios se permite centralizar o descentralizar las comunicaciones Jabber/XMPP dentro de la red empresarial, con todas las ventajas e inconvenientes que ello supone. Se podra llegar a dos extremos, en los que en uno habra millones de usuarios conectados a un nico servidor central, o al extremo opuesto en que habra prcticamente un servidor por cada usuario. El primer extremo sera ideal de cara a la seguridad y nefasto por el cuello de botella que ello generara El otro modelo sera muchsimo menos seguro, pero la conexin entre los usuarios del mismo dominio tendra un ancho de banda fuera de lo comn en una red de MI. Como todo el mundo sabe los extremos no son buenos nunca, lo ideal es la organizacin de los clientes y servidores en una red con el fin de que la seguridad tampoco implique quedarse sin ancho de banda para las conexiones, siempre hay un trmino medio y con ello hay que jugar.

2.1.4.

Encaminamiento de los paquetes Jabber/XMPP

Lo primero que debemos de entender es que los paquetes son enviados a un destinatario lgico, es decir, a un cliente y no a un equipo remoto como sera el caso de una conexin punto a punto. Es responsabilidad del encaminamiento del servidor Jabber/XMPP asegurarse que los paquetes llegan al usuario destinatario donde quiera que se encuentre en la red, o si no est conectado almacenarlos para envirselos cuando se autentifique. Tambin hay que darse cuenta que la MI transcurre a travs del espacio y del tiempo, los paquetes recorren la red y el servidor debe saber cuando recogerlos y guardarlos y cuando reenviarlos a su destinatario. Para ello debe saber si un usuario se encuentra conectado, y si es as, saber desde dnde est conectado para hacerle llegar los paquetes. Adems los paquetes deben

10

llegar al destinatario lo antes posible si el usuario est conectado, y si no, como ya se ha dicho, almacenarlos y hacrselos llegar en cuanto sea factible. El servidor se basar en el atributo to del mensaje para identificar el destinatario del mismo. En este atributo el cliente emisor deber haber puesto el Jabber ID del destinatario, que es todo lo que el servidor debe conocer para hacer llegar ese paquete a su fin. Coger la parte del Jabber ID del nombre del servidor (la parte que sigue al carcter @) para saber si el destinatario pertenece a su dominio, si es as extraer el nombre (la parte que precede al carcter @) y lo buscar entre sus usuarios, si el cliente est conectado se lo enviar, si no es as, lo guardar para envirselo en cuanto sea posible. Si el destinatario no pertenece a su dominio, se conectar con el servidor responsable del dominio, que deber tener el nombre del dominio para ser localizado, y le enviar el mensaje actuando en representacin de su cliente.

2.2.

Ejemplo de una sesin Jabber/XMPP

Gracias a los esfuerzos del protocolo para facilitar su lectura usando mensajes XML, y la sencillez de su estructura se puede seguir de una manera fcil una sesin simple de comunicacin Jabber/XMPP. Adems para un mejor entendimiento de cada protocolo hay que tener una idea general de cmo funciona realmente Jabber/XMPP. Para ello vamos a mostrar una conexin entre dos usuarios Jabber/XMPP, que seguir este sencillo esquema: Oscar: 1. Conexin con el servidor [Link]. 2. Enviar la etiqueta de inicio de sesin. 3. Registrarse como usuario oscar y contrasea oscarpass. 4. Autentificarse como oscar en el servidor. Iaki: 5. Conectarse con el servidor [Link]. 6. Enviar la etiqueta de inicio de sesin. 7. Registrarse como usuario iaki y contrasea iakipass. 8. Autentificarse como Iaki en el servidor. Oscar: 9. Enviar un mensaje al usuario iaki. 10. Actualizar la presencia a available. Iaki: 11. Actualizar la presencia a available. 12. Recibir el mensaje de oscar. 13. Enviar un mensaje a oscar.

11

Oscar: 14. Recibir el mensaje de iaki. 15. Cerrar la sesin. Iaki: 16. Cerrar la sesin. Antes de empezar a desarrollar la conexin entre el servidor y estos dos usuarios hay que recordar que se puede reproducir ntegramente esta sesin abriendo la consola del sistema operativo y ejecutando la herramienta telnet para conectarse al servidor que el usuario desee. Para ello bastar con escribir en la lnea de comandos: telnet [Link] 5222 donde [Link] es el servidor al que nos queremos conectar, y 5222 es el puerto por defecto de los servidores Jabber. Los pasos 1-4 y 5-8 son idnticos, lo nico que vara es el nombre y la contrasea del usuario, as que slo se mostrar la sesin de oscar. Se mostrar en negrita lo que el usuario escribe, y lo dems ser la respuesta del servidor: o Paquetes 1,5: Nos conectamos haciendo telnet al servidor de [Link] en el puerto 5222
% telnet [Link] 5222 Trying [Link]... Connected to [Link]. Escape character is '^]'.

o Paquetes 2,6: Enviamos el tipo de xml que vamos a utilizar y la etiqueta <stream:stream> con la informacin opcional del tipo de etiqueta. El servidor nos devuelve la misma etiqueta y nos informa del id de la sesin y de su nombre Jabber/XMPP.
<?xml version='1.0'?> <stream:stream xmlns:stream='[Link] xmlns='jabber:client' to='[Link]'> <?xml version='1.0'?> <stream:stream xmlns:stream='[Link] id='3C0FB73C' xmlns='jabber:client' from='[Link]'>

o Paquetes 3,7: Damos de alta el usuario oscar con la contrasea oscarpass con un mensaje iq de tipo set. El tipo de peticin (query) es jabber:iq:registrer para que el servidor sepa que el usuario lo que quiere es registrar su cuenta y no autentificarse.
<iq type='set' id=reg_id> <query xmlns='jabber:iq:register'> <username>oscar</username> <password>oscarpass</password>

12

</query> </iq> <iq type='result'/>

o Paquetes 4,8: Lo mismo que en el punto anterior, pero el tipo de peticin (query) esta vez sigue el protocolo de jabber:iq:auth que es el de autentificacin de un usuario, nos estamos logeando.
<iq type='set' id=auth_id> <query xmlns='jabber:iq:auth'> <username>oscar</username> <password>pass</password> </query> </iq> <iq type='result' id='client_auth_ID'/>

o Paquete 9: Oscar enva el mensaje al usuario Iaki, con el ttulo y el cuerpo.

<message to='iaki@[Link]'> <subject>Hola</subject> <body>Este es el cuerpo del mensaje</body> </message>

o Paquete 10: Oscar enva una actualizacin de su presencia a available para hacer saber al servidor que ya se encuentra disponible. Y el servidor le da la bienvenida.
<presence type='available'/> <message from='[Link] to='oscar@[Link]'> <subject>Welcome!</subject> <body>Welcome to Jabber! </body> </message>

o Paquetes 11 y 12: Iaki actualiza su presencia enviando simplemente la etiqueta presence, lo que el servidor interpreta por defecto que el cliente est available. A lo cual el servidor responde con un mensaje de bienvenida y con el mensaje que oscar le haba enviado y que tena almacenado para cuando se conectara.
<presence/> <message from=' [Link]' to=iaki@[Link]'> <subject>Welcome!</subject> <body>Welcome to Jabber! </body> </message> <message to='iaki@[Link]'

13

from='oscar@[Link]'> <subject>Hola</subject> <body>Este es el cuerpo del mensaje</body> </message>

o Paquete 13: Iaki enva un mensaje a oscar como respuesta.

<message to='oscar@[Link]'> <body>gracias por tu mensaje</body> </message>

o Paquete 14: Oscar recibe el mensaje.

<message to='oscar@[Link]' from='iaki@[Link]' <body>gracias por tu mensaje</body> </message>

o Paquetes 15 y 16: Y los dos usuarios se desconectan enviando la etiqueta de cierre de la sesin.
</stream:stream> Connection closed by foreign host.

Como puede verse la comunicacin en Jabber/XMPP es simple y muy intuitiva para el usuario gracias a su formato XML. Se puede entender fcilmente la comunicacin con solo unas bsicas nociones de lo que se est realizando.

14

3. Message protocol
Los mensajes son la parte ms importante de la MI, por ello el protocolo de mensajes de Jabber/XMPP es simple pero poderoso. El envo de mensajes es la mayor responsabilidad de cualquier sistema Jabber/XMPP, por ello se han desarrollado seis tipos de mensajes: o normal: que seran mensajes parecidos a los del correo electrnico. o chat: mensajes persona a persona que seran los mensajes utilizados en una conversacin entre dos personas. o groupchat: mensajes enviados a un grupo de personas o headline: que seran los mensajes de marquesina. o error: para los mensajes de error. o jabber:x:oob: para las conexiones directas entre clientes para envo de archivos. Los cinco primeros son los tipos ms normales de mensajes en los sistemas Jabber/XMPP. Los mensajes jabber:x:oob se denominan Out-ofband messages, y facilitan un mecanismo para intercambio de datos directamente entre dos usuarios, estos mensajes usan el servidor Jabber/XMPP para intercambiar datos de la conexin entre los dos clientes, normalmente el usuario que va a servir un fichero enviara un mensaje de este tipo al otro cliente con la IP y el puerto al que se debe conectar el cliente que va a descargarse el [Link] pueden enviar etiquetas de oob dentro de la extensin x de un mensaje normal, o empaquetadas dentro de un paquete del tipo Info/Query. El protocolo de mensajes es extremadamente sencillo, los paquetes son enviados por un usuario a un receptor. Por defecto, no se reciben confirmaciones de que el mensaje ha sido recibido por el destinatario para reducir el trfico en el servidor, adems si el receptor no se encuentra disponible, el servidor guardar el mensaje hasta que se conecte, a este protocolo se le llama store and forward. Un mensaje bsico consiste en la etiqueta <message> con el tpico from, to y el id del paquete como atributos. Adems este tipo de paquetes soporta cuatro subelementos: o <subject>: indicando el ttulo o tema del mensaje, como en los emails. o <thread>: identificador generado por el cliente para identificar la conversacin a la que pertenece el mensaje.

15

o <body>: el mensaje en s ira en esta etiqueta.

o <error>: si ocurriera algn error, esta etiqueta se encontrara en el mensaje. As un mensaje tpico sera el siguiente:
<message from='oscar@[Link]/trabajo' to='iaki@[Link]/casa' id='messageid1'> <thread>threadid_01</thread> <subject>Ttulo del mensaje</subject> <body>Cuerpo del mensaje</body> </message>

Pero muchos de estos campos no son obligatorios ya que por ejemplo el id y el thread son para un manejo ms fcil de los mensajes en los clientes, no todos los mensajes tienen por qu tener ttulos y adems el campo from no es necesario ya que para evitar que una persona enve mensajes poniendo como origen un Jabber ID que no es el suyo el servidor reescribir el campo from del paquete antes de enviarlo a su destinatario, as pues, si nos hemos conectado como el usuario usuario1 y enviamos este paquete, a Iaki no le llegar en el campo from oscar@[Link]/trabajo, si no usuario1@[Link]. As pues un mensaje podra ser mucho ms corto y ocupar menos ancho de banda en su transmisin, como el siguiente ejemplo enviado por oscar:
<message to='iaki@[Link]'> <body>Hola!</body> </message>

Y al destinatario le llegara:
<message from='oscar@[Link]/trabajo' to='iaki@[Link]'> <body>Hola!</body> </message>

El tipo por defecto de mensajes es el normal message. Estos mensajes son normalmente creados y enviados usando interfaces similares a las usadas en las aplicaciones de correo electrnico. Como el correo electrnico, estos mensajes son enviados a usuarios, sin la necesidad de que el destinatario est conectado. Los mensajes que no contienen el tipo son considerados como normales. Pero por supuesto se puede poner el tipo a normal. Los usuarios usan los mensajes de tipo chat para enviarse entre ellos mensajes instantneos. Estos mensajes suelen ser cortos, ya que se utilizan para llevar a cabo una conversacin entre dos personas. Estos mensajes son normalmente mostrados en una interfaz de tipo chat, en la que el usuario puede ir viendo lo que escribe el y lo que escribe su contacto.

16

Los mensajes de tipo chat deben de llevar puesto obligatoriamente el campo del tipo con el valor chat porque si no seran considerados como normales, al igual que el resto de los mensajes. Normalmente no llevan nunca el campo del ttulo del mensaje. Estos mensajes son para conversaciones entre dos clientes nicamente, para conversaciones entre ms de dos clientes se usan los mensajes groupchat. Los mensajes del tipo groupchat son similares a los mensajes del tipo chat, pero estn diseados para mantener conversaciones entre un grupo de personas sobre un tema en concreto. Por ello cuando un cliente enva un mensaje al grupo, todos los clientes que se hayan unido al grupo recibirn el mensaje, aunque tambin se podr escribir mensajes de este tipo privados dirigidos a un usuario en concreto. Para formar parte de un grupo es necesario unirse a l con un sobrenombre nickname que ser mostrado al resto de los usuarios. Esto est pensado para ocultar la identidad real de los participantes ya que si un usuario se conecta al grupo usuarios-xp@[Link] como pepe, a los dems usuarios no les aparecer su verdadero Jabber ID:oscar@[Link] lo que realmente les aparecer ser usuariosxp@[Link]/pepe y todos los mensajes que yo enve al grupo llegarn con ese identificativo, al igual que si escribo a un usuario en concreto del grupo le llegar este mismo identificativo y me deber dirigir a l en el mismo formato, ya que slo conozco al grupo al que pertenece y su nickname. As un mensaje que enva el usuario del grupo usuariosxp@[Link] con nick pepe aunque sea privado le llegar al usuario Iaki que se ha conectado con el nick de paquito de la siguiente manera: o Mensaje enviado:
<message from='oscar@[Link]/trabajo' to=usuarios-xp@[Link]/paco' id='messageid4' type='groupchat'> <thread>threadid_04</thread> <body>Texto del mensaje</body> </message>

o Mensaje recibido:
<message from=usuarios-xp@[Link]/pepe' to='iaki@[Link]/casa' id='messageid4' type='groupchat'> <thread>threadid_04</thread> <body>Texto del mensaje</body> </message>

Como puede verse el servidor ha cambiado el usuario destino por el Jabber ID original del destinatario, y en el mensaje que ha llegado a iaki, el origen del mensaje tambin ha sido cambiado para ocultar su identidad. Si se

17

hubiera querido enviar un mensaje al grupo entero sera igual, salvo el campo to que no llevara /paco porque ira a todo el grupo.

Los mensajes del tipo headline message estn diseados para mostrar informacin en la barra de estado o en otras partes de la interfaz de usuarios. Los usan comnmente los chatbots para informar de noticias, alertas del tiempo a los usuarios que se den de alta en estos servicios automatizados. No requieren del las etiquetas <thread> o <subject>. Otro tipo de mensajes son los mensajes de error, cuando un cliente enva un mensaje y se produce un error, ya sea que el cliente al que va dirigido no existe, o que sencillamente el mensaje ha sido rechazado por el cliente destinatario. Estos son los errores ms comunes del ncleo de Jabber: 400 Peticin errnea. 401 Desautorizado. 402 Servicio de pago. 403 Prohibido. 404 No encontrado. 405 No permitido. 406 No aceptable. 407 Registro requerido. 408 Timeout. 409 Conflicto. 500 Error interno del servidor. 501 No implementado. 502 Error del servidor remoto. 503 Servicio no disponible. 504 Timeout de servidor remoto. Estos cdigos son vlidos en Jabber-core, pero han cambiado en XMPP. Por ltimo estn los Out-of-band messages, que no son realmente un mensaje convencional de Jabber/XMPP. En cambio, es una extensin de los mensajes que es enviada dentro de un mensaje normal. Un mensaje de este tipo contiene normalmente informacin, normalmente una URL, que el cliente desea usar para realizar una transferencia de datos punto-a-punto sin pasar por el servidor. Los cliente normalmente lo suelen implementar arrancando un servidor Web o un FTP separadamente o como parte del cliente Jabber/XMPP. Por lo tanto estn dando a otro cliente la informacin de su IP y el puerto que han abierto para que el otro cliente se descargue el archivo. Esto es ideal para el intercambio de ficheros entre clientes ya que con ello consigues reducir el trfico que pasa por el servidor, pero como siempre que un cliente revela su IP tiene sus riesgos, si la persona a la que el usuario enva

18

esta informacin es un usuario malintencionada podra utilizar la IP con otros fines muy distintos a los de descargarse el fichero que el cliente le est ofreciendo.

19

4. Presence protocol
Entre otras cosas la MI se diferencia del correo electrnico en la posibilidad que tienen los usuarios de detectarse los unos a los otros y saber cuando un usuario se encuentra conectado. Adems hoy en da se va ms all y podemos saber si aunque est conectado al sistema de MI en ese instante est ocupado haciendo algo y debemos esperar para hablarle o si est conectado pero se ha ido, no est frente al ordenador. Adems Jabber/XMPP nos ofrece la posibilidad de poner tantos estados diferentes como desee el usuario, as siempre se sentir ms identificado con el estado en el que pone su sistema de MI. Esto es muy importante porque si un usuario se encuentra conectado, porque est esperando a que alguien se conecte porque tiene que charlar con l, pero est muy ocupado trabajando, lo que menos necesita es que le lleguen constantemente mensajes a su aplicacin y le molesten, por ello pondr su estado a ocupado, y sus contactos debern respetarlo y no molestarlo a no ser que sea algo importante Este es uno de los mltiples servicios que se pueden encontrar al protocolo de presencia. Adems Jabber/XMPP se ha preocupado de la intimidad de los usuarios, y si un usuario quiere agregar a otro en su lista de contactos, y recibir su presencia, deber pedrselo al servidor, y si el cliente que va a ser espiado acepta, entonces podr ver su estado. Esto es as porque si un usuario no quiere que una persona sepa cuando est conectado, cuando est comiendo est en tu derecho a la intimidad, y ser l quien decida quin puede conocer su estado actual. El protocolo de presencia es usado principalmente en dos contextos: o Presence update: actualizacin de la presencia debido a un cambio de estado del usuario. o Presence subscription management: permite a los usuarios subscribirse a las actualizaciones de presencia de otros usuarios y controlar quien est accediendo a su propia presencia. En ambos casos el servidor de Jabber/XMPP acta como rbitro entre el emisor de la actualizacin de presencia y los destinatarios de la misma. El servidor tiene la obligacin de hacer llegar el paquete de actualizacin de presencia a todos los contactos del cliente que lo gener, pero slo a los contactos que el cliente emisor ha confirmado que le gustara que recibieran su presencia. El servicio de actualizacin de presencia usa un simple mensaje unidireccional del emisor al servidor de su dominio, es el servidor el que tendr que copiar y reenviar el mensaje de presencia a todos los clientes del emisor. El servidor mira la lista de contactos del emisor para conocer quienes son sus contactos, esta lista de contactos en Jabber/XMPP se llama Roster. Como 20

puede verse se ha intentado reducir las responsabilidades del cliente al mnimo para favorecer el diseo de clientes Jabber/XMPP, y dejar toda la responsabilidad al servidor. Como ya se ha dicho, la lista de contactos (Roster), se guarda en el servidor. Esto es as porque el cliente siempre tendr su roster actualizado, aunque cambie de aplicacin o de ordenador, gracias a que no es l quien guarda esos datos, si no el servidor de su dominio. Los clientes enviarn y recibirn mensajes de suscripcin de presencia de dos tipos:subscribe y unsubscribe. Estos mensajes deben de ir llegando a su destinatario, pero sin embargo el servidor deber escuchar y actualizar la presencia de su cliente segn estos mensajes. Este tipo de suscripcin de presencia tambin es usada en los mensajes de grupo que veremos ms adelante. Los mensajes de presencia tienen los atributos to, from y type como viene siendo habitual para todos los tipos de mensajes Jabber/XMPP. Estos nos sirven para redirigir los paquetes y determinar su tipo. Estos son los diferentes tipos de presencia: o available: mensaje de actualizacin que indica que el usuario est listo para recibir mensajes. o unavailable: mensaje de actualizacin que indica que el usuario no est disponible para recibir mensajes. o subscribe: mensaje de peticin de suscripcin de presencia, el usuario que lo enva desea suscribirse a la presencia del destinatario. o unsubscribe: mensaje de cancelacin de suscripcin de presencia, el usuario que lo enva desea cancelar su suscripcin a la presencia del destinatario. o subscribed: respuesta que recibir un usuario que ha realizado una peticin de suscripcin, que indica el estado actual de la suscripcin. o unsubscribed: respuesta que recibir un usuario que ha realizado una peticin de suscripcin y le ha sido negada, o una peticin de cancelacin de la suscripcin. o error: mensaje estndar de error de Jabber/XMPP que indica problemas en la presencia. o probe: peticin Servidor-a-Servidor que enva toda la informacin de presencia de un servidor a otro. El protocolo de presencia permite adems cuatro sub-etiquetas ms en el paquete de presencia: o <status>: texto libre para que el usuario explique su estado actual.

21

o <priority>: prioridad numrica del mensaje, los nmeros ms altos tienen ms prioridad. Slo se admiten nmeros enteros positivos. o <error>: paquete estndar de error de Jabber/XMPP. o <show>: Uno de los cuatro estados estndar que los clientes pueden usar para modificar su presencia available. Los clientes Jabber/XMPP usarn normalmente el estado show para mostrar iconos de presencia estndar, alertas sonoras y otras cosas. Si el estado show no est indicado, el usuario se encuentra en estado normal o online. Los estados estndar para show son: o chat: el usuario est intentando hablar con alguien. o away: el usuario est fuera del cliente Jabber/XMPP por un corto periodo de tiempo. o xa (extended away): el usuario est fuera por un periodo prolongado de tiempo. o dnd (do not distrub): el usuario no desea recibir mensajes.

Un ejemplo de actualizacin de presencia es el siguiente:

<presence from='oscar@[Link]/trabajo' to='[Link]' type='available'> <status>Estoy aburrido, que alguien me hable</status> <priority>10</priority> <show>chat</show> </presence>

Normalmente se estn mostrando los campos opcionales en todos los ejemplos para hacerlos ms claros, pero un ejemplo mucho ms corto de presencia podra ser simplemente <presence/>, en el que el cliente simplemente indicara a sus contactos que est presente. Pero un ejemplo mucho ms tpico y compacto que el primero sera el siguiente:
<presence> <status> Estoy aburrido, que alguien me hable </status> <show>chat</show> </presence>

El efecto sera prcticamente el mismo que el primero, salvo la prioridad del mensaje, y como puede observarse este ejemplo consumira bastante menos ancho de banda de la red empresarial que el primero. Y en ambos casos a mis contactos les llegara el mismo mensaje:
<presence from='oscar@[Link]/trabajo' to='iaki@[Link]'> <status>Estoy aburrido, que alguien me hable</status> <show>chat</show> </presence>

Esto es debido a que como en el protocolo de mensajes, el servidor reescribir el atributo from y aadir el campo to para cada uno de los contactos que deban recibir la presencia. 22

Los paquetes de suscripcin de presencia usan un protocolo de peticinrespuesta. Este sera un ejemplo de una peticin-respuesta de suscripcin:
<presence from='oscar@[Link]/trabajo' to='iaki@[Link]/casa' type='subscribe'/> <presence from='iaki@[Link]/casa' to='oscar@[Link]/trabajo' type='subscribed'/>

En el primero Oscar enva una peticin de suscripcin a la presencia de Iaki, y recibi la confirmacin de suscripcin por parte de Iaki. La respuesta no suele ser as de rpida, ya que Iaki no tiene por qu estar conectado en ese momento, y hasta que no se conecte no recibir la peticin de Oscar, en ese momento deber confirmarla o rechazarla, y entonces le llegar la confirmacin a Oscar, que si lo llevamos a casos extremos puede que tampoco se encuentre conectado y la recibir la prxima vez que se conecte. Si Iaki hubiera rechazado la suscripcin en lugar de una confirmacin subscribed el tipo hubiera sido unsubscribed. La presencia es usada por Jabber/XMPP con varias finalidades, entre las cuales la ms popular y ms usada es la de dar a conocer a otros usuarios el estado actual de cada cliente y saber cuando estn ocupados o libres para hablar entre ellos. Adems los mensajes de tipo groupchat usan la presencia de una forma muy simple. Se juntan para crear grupos de conversaciones, darse de alta y de baja de ellos

23

5. Groupchat protocol
Existen cuatro acciones fundamentales que un usuario debe ser capaz de hacer en un groupchat: o Unirse al grupo: enviando una presencia de tipo available al grupo. o Enviar mensajes a todo el grupo: enviando un mensaje de tipo groupchat al Jabber ID del grupo deseado, al que previamente el usuario se ha debido de unir. o Enviar mensajes a un nico miembro del grupo (mensajes privados): enviando un mensaje de tipo groupchat a una persona del grupo, poniendo tras el Jabber ID del grupo el carcter / y el nickname de la persona. o Abandonar el grupo: enviando un mensaje unavailable de presencia al grupo. Como se puede ver, para unirse y abandonar un grupo se usa el protocolo de presencia, y para enviar mensajes, ya sean a todo el grupo, o mensajes privados se usa el protocolo de mensajes, pero con el tipo groupchat. Para unirse a un grupo, se usa una actualizacin de presencia especificando el nickname que el usuario va a utilizar a lo largo de la sesin. En el siguiente ejemplo nos conectaremos con el nick pepe al grupo xpusers@[Link]:
<presence to='xp-users@[Link]/pepe' from='oscar@[Link]/trabajo'/>

El servidor de groupchat asociar mi Jabber ID con el nickname pepe en su lista interna de usuarios. Una vez que me aada a lista me enviar el siguiente mensaje confirmndome mi suscripcin al grupo:
<presence to='oscar@[Link]/trabajo' from='xp-users@[Link]/pepe'/>

Adems enviar un mensaje de informacin al grupo advirtiendo de mi incorporacin al mismo, que por supuesto yo tambin recibir:
<message to='oscar@[Link]/trabajo' from='xp-users@[Link]' type='groupchat'> <body>pepe has joined xp-users</body> </message>

Como se puede ver en el atributo from del mensaje el emisor del mismo es el grupo en s, ya que no tiene el nickname de ningn usuario. Si Iaki se une al grupo la secuencia sera la siguiente:

24

Iaki se une al grupo:

<presence from='iaki@[Link]/casa' to='xp-users@[Link]/paco'/>

Iaki recibe del servidor:

<presence <presence <message to='iaki@[Link]/casa' from='xp-users@[Link]/pepe'/> to='iaki@[Link]/casa' from='xp-users@[Link]/paco'/>

to=iaki@[Link]/casa' from='xp-users@[Link]' type='groupchat'> <body>paco has joined xp-users</body> </message>

En el que podemos observar que el servidor le informa a iaki de cada usuario que est conectado al grupo, en este caso pepe y paco que es el, y enva el mensaje al grupo entero de informacin sobre un nuevo usuario. Oscar por su parte recibir:
<presence <message to='oscar@[Link]/trabajo' from='xp-users@[Link]/paco' />

to='oscar@[Link]/trabajo' from='xp-users@[Link]' type='groupchat'> <body>paco has joined xp-users</body> </message>

Recibe la presencia de un usuario nuevo, y el mensaje informativo del suceso. Si yo soy oscar, no se la verdadera identidad de paco, tan solo se que su nickname es paco, pero puedo enviarle un mensaje directamente a l porque el servidor del grupo se encargar de reenvirselo a Iaki.
<message to='xp-users@[Link]/paco' from='oscar@[Link]/trabajo' type='groupchat'> <body>Hola paco!!!</body> </message>

Por supuesto el servidor har llegar el mensaje a iaki(paco), pero deber ocultar tambin mi identidad:
<message to='iaki@[Link]/casa' from='xp-users@[Link]/pepe' type='groupchat'> <body> Hola paco!!!</body> </message>

25

Como vemos ninguno de los dos puede saber el verdadero Jabber ID del otro, slo conocen el grupo al que ambos se encuentran conectados, y el sobrenombre que el otro utiliza en el grupo. Veamos ahora como llegara un mensaje que enva Iaki (paco) a todo el grupo:
<message to='xp-users@[Link] from='iaki@[Link]/casa' type='groupchat'> <body>Hay alguien ah?</body> </message>

El servidor del grupo recibir el mensaje y lo reenviar a cada miembro del grupo sustituyendo el origen del mensaje por el nickname de Iaki, y el destinatario que ser el cliente que lo deba recibir en cada caso, veamos como les llega el mensaje a Iaki y a Oscar:
<message to='iaki@[Link]/casa' from='xp-users@[Link]/paco' type='groupchat'> <body> Hay alguien ah?</body> </message> <message to='oscar@[Link]/trabajo' from='xp-users@[Link]/paco' type='groupchat'> <body> Hay alguien ah?</body> </message>

Si Iaki se debe de ir, y quiere abandonar el grupo enviar un mensaje de presencia unavailable al grupo:
<presence to='xp-users@[Link]/paco' from='iaki@[Link]/casa' type='unavailable'/>

Iaki recibir la confirmacin del grupo de su marcha del mismo:

<presence to='iaki@[Link]/casa' from='xp-users@[Link]/paco' type='unavailable'/>

Y Oscar recibir la actualizacin de la presencia y un mensaje informando de la marcha de paco:

<presence to='oscar@[Link]/trabajo' from='xp-users@[Link]/paco' type='unavailable'/>

<message

to='oscar@[Link]/trabajo' from='xp-users@[Link]' <body>paco has left</body> </message>

26

6. Info/Query protocol
Este tipo de mensajes como bien indica su nombre son de peticinrespuesta, as que cuando un cliente enva un mensaje IQ siempre deber recibir una respuesta del destinatario, aunque sea te tipo error. Un usuario en Jabber/XMPP representa a una persona. Los clientes Jabber/XMPP actan en representacin de un determinado usuario, y un usuario en particular puede tener varios clientes activos simultneamente. Como ya se ha mencionado con anterioridad los clientes que actan en representacin de un usuarios son llamados resources, y se indica al final del Jabber ID del usuario. El usuario es representado en el sistema Jabber/XMPP por una cuenta de usuario almacenada y gestionada en el servidor Jabber/XMPP del dominio. Los clientes se autentifican con el servidor Jabber/XMPP usando la informacin de autentificacin. Una vez el usuario se ha autentificado, el cliente puede descargar o actualizar la informacin de su cuenta de usuario almacenada en el servidor. Este protocolo se centra fundamentalmente en los procedimientos para crear y almacenar la informacin de un usuario en el servidor. Aunque la mayora del trfico de un sistema de MI Jabber/XMPP est compuesto de mensajes y presencias, el mayor esfuerzo a la hora de implementar un cliente o servidor Jabber/XMPP radica en la administracin de las cuentas de usuarios. Jabber/XMPP ha implementado un protocolo de peticin/respuesta para gestionar estas peticiones. IQ es un protocolo sencillo y ampliable de peticin-respuesta que permite a los usuarios hacer peticiones, y almacenar o cambiar datos usando un sencillo protocolo. IQ es simplemente el conductor de esas peticiones y respuestas, y gestiona qu datos son necesarios de acuerdo con las necesidades particulares de cada servidor. IQ es totalmente ampliable por los desarrolladores, que encuentran en este servicio de IQ el lugar idneo para sus ampliaciones de gestin. La mayora de las peticiones IQ son entre un cliente y un servidor. Sin embargo, hay algunos protocolos de IQ que van estrictamente de un cliente a otro, como el protocolo de peticin de versin del cliente, en que un cliente le pedir al otro su versin del programa. El protocolo IQ tiene dos participantes, el que genera la peticin y el que la trata. Pueden darse dos situaciones, una comunicacin entre un cliente y un servidor, en la que el cliente ser quien enve los paquetes IQ, o entre dos cliente, en cuyo caso un cliente realiza una peticin a otro cliente el cual le deber responder.

27

El protocolo comienza con una peticin de un cliente a otro cliente o servidor que gestionar su peticin. El paquete IQ ser encaminado por el sistema Jabber/XMPP como cualquier otro paquete hasta ser entregado a su destinatario. Pero al contrario de un mensaje Jabber/XMPP, el paquete no ser almacenado si el receptor del paquete no se encuentra disponible. Adems los paquetes IQ que se dirigen a un usuario no pueden ser enviados al Jabber ID de un cliente, hay que especificar el cliente concreto de ese Jabber ID, es decir, habr que especificar el resource. A no ser que el destinatario sea un servidor, que en tal caso el paquete si puede ir dirigido al servidor o incluso no mencionar el destinatario si es el servidor de tu dominio. Ya se coment anteriormente que el servidor adopta como suyos todos los paquetes que no tienen destinatario. Los paquetes IQ pueden ser de dos tipo, set o get, el primero como se sobreentiende es para modificar datos que posee el destinatario del paquete, y el segundo para solicitarlos. El destinatario tratar el paquete y enviar una respuesta siempre, en el primer caso responder si se han podido modificar correctamente o si ha habido algn tipo de error, y en el segundo caso nos devolver la informacin que le hemos solicitado o un mensaje de error. El formato de un paquete IQ sera el siguiente:
<iq type='set|get|result|error' to='jid_destino' from='jid_origen' id='unica'> <query xmlns='iq extension namespace'> <query_field1/> <query_field2/> </query>

</iq>

El atributo type indica el tipo de peticin que se va a enviar, que ser uno de los siguientes tipos: o get: el emisor solicita informacin al destinatario. o set: el emisor solicita la actualizacin de los datos que tiene el destinatario. o result: respuesta de una solicitud IQ anterior. o error: respuesta de error en el procesamiento de una peticin IQ anterior.

Como puede observarse los dos primeros tipos seran los que utilizara el cliente que emita la peticin IQ y los dos ltimos seran las dos posibles respuestas de quien reciba la peticin. Tambin hay que fijarse que se pueden dar varias peticiones/respuestas <query> dentro de un mismo mensaje iq. Esto es sobre todo ms habitual en la respuesta que el la pregunta, ya que si por ejemplo un cliente solicita a su servidor la lista de contactos, el cliente enviar una nica peticin, pero el servidor responder con un <query> por cada 28

contacto que ese cliente tenga almacenado en el servidor, es algo similar a una respuesta de una sentencia SQL que devuelve mltiples resultados de acuerdo a la peticin que le hemos hecho. Hay que mencionar que un paquete iq no tiene porqu tener obligatoriamente sub-elementos <query>. Muchas veces las respuestas no contienen ningn elemento <query>. Pero los paquetes iq pueden tener tambin otros elementos como pueden ser los <vCard>. Los emisores de peticiones IQ no tienen que esperar a la respuesta para poder enviar otra peticin IQ, tampoco deben esperar que las respuestas a sus peticiones lleguen en el mismo orden en que las enviaron, para distinguir las respuestas se guiarn de la etiqueta id que ser igual tanto en la peticin como en la respuesta. Esta identificacin la genera el cliente al hacer la consulta y el destinatario la copiar en la respuesta, ya sea una respuesta de error o un resultado. Como puede verse en el ejemplo la etiqueta <iq> por si sola contiene adems de los atributos tpicos de Jabber/XMPP elementos <query>. Esto permite a los servidores tratar a todos los paquetes iq de la misma forma, sin tener que conocer el contenido de las peticiones, si es que no van dirigidas a ellos. Esto es muy importante, ya que as pueden implementarse peticiones que no pertenezcan al protocolo, y sern reconducidas perfectamente por todos los servidores de Jabber/XMPP, aun desconociendo el contenido de las peticiones, por ello es muy importante este formato en el que Jabber/XMPP encapsula las peticiones dentro del paquete iq. Esto abre las puertas a los desarrolladores a la hora de ampliar el protocolo Jabber/XMPP y adaptarlo a sus necesidades, y libera a los servidores de tener que conocer todos los tipos de peticiones aunque no las tuvieran que tratar nunca. Los paquetes <query> que van dentro de los paquetes <iq> establecen un namespace XML usando el atributo xmlns. Cada namespace establece una extensin IQ con sus propias etiquetas y atributos, y un protocolo para su procesamiento. As que si nos encontramos que el atributo xmlns contiene jabber:iq:foobar la peticin seguir el protocolo foobar que pertenece a una extensin de iq, y para tratarlo el servidor o cliente destinatario deber conocer tambin dicha extensin, si no devolver una respuesta de error. Normalmente los elementos <query> contienen simplemente hijos que representan etiquetas de datos. En peticiones IQ de tipo get las etiquetas rellenas servirn al destinatario para realizar la bsqueda y las vacas sern los campos que pide el cliente, as que en la respuesta al cliente los campos que envi vacos deberan de volver rellenos. Si por ejemplo realizamos una extensin que definimos como my:query:namespace y se trata de una bsqueda entre los contactos del usuario, un ejemplo de esa peticin sera:
<iq type='get' to='[Link]' from='yo@[Link]'> <query xmlns="my:query:namespace"> <name-first>Igor</name-first>

29

<name-last/> <email/> </query> </iq>

Y su respuesta:
<iq type='result' to='yo@[Link]' from='[Link]'> <query xmlns='my:query:namespace'> <name-first> Igor </name-first> <name-last>Garca</name-last> <email>IgorGarcia@[Link]</email> </query> <query xmlns='my:query:namespace'> <name-first> Igor </name-first> <name-last>Snchez</name-last> <email>igorSanchez@[Link]</email> </query> </iq>

La mayora de los patrones de peticin-respuesta bsicos siguen este modelo. La mayor diferencia entre las diferentes extensiones del protocolo IQ son los campos y su significado para quien lo enva y para quien procesa la peticin. Las extensiones de IQ se organizan segn las necesidades de cada aplicacin. El diseo del protocolo IQ permite una rpida y eficiente forma de agregar tus propias extensiones, siempre que tanto el emisor como el receptor entiendan la extensin y la tengan implementada para poder tratarla adecuadamente. Pueden perfectamente operar dentro de una red estndar de Jabber/XMPP dos clientes que conozcan una extensin propia y necesiten usarla, ya que la extensin va empaquetada dentro del estndar IQ y ser reenviada correctamente por el servidor o servidores Jabber/XMPP por las que tenga que pasar. Existen actualmente ms de 15 extensiones de IQ dentro del protocolo Jabber/XMPP y otras 10 en fase de desarrollo, que dentro de poco sern parte del estndar. Pero cualquier desarrollador puede implementar sus propias extensiones segn sus necesidades. Pasemos a ver a fondo las extensiones IQ ms importantes.

30

6.1.

Registration protocol (jabber:iq:register)

El primer paso para poder tener usuarios en el servidor es dejar a los usuarios crear sus cuentas en el servidor mediante esta extensin del protocolo IQ. Esto no ocurrir as en un servidor de uso privado de una red empresarial, en el que uno de los factores importantes es la seguridad. Pero para cualquier servidor pblico de Jabber/XMPP es necesario implementar el protocolo de registro para que cualquier persona que lo desee pueda registrarse y unirse a la comunidad de usuarios Jabber/XMPP. Esta extensin es usada para tres propsitos: o Crear cuentas de usuario. o Actualizar la informacin de las cuentas de usuario. o Borrando cuentas de usuario. Como ya hemos dicho este protocolo es usado especialmente en los servidores pblicos de Jabber/XMPP que proveen del servicio de MI Jabber/XMPP al pblico en general. Obviamente, no en todas las situaciones los administradores de los servidores Jabber/XMPP dejarn al pblico crear sus propias cuentas de usuarios sin permiso. La situacin es parecida a la de los servidores de correo, nuevamente, como todo el mundo sabe existen servidores de correo que cobran por sus servicios, o que ofrecen sus servicios como un complemento adicional a otro servicio principal, en estos servidores un usuario cualquiera no puede darse de alta y disfrutar de una cuenta de correo. Sin embargo, existen otros servidores de correo, llammoslos pblicos, en los que cualquier persona puede dar de alta una cuenta de correo una vez introducidos unos datos personales mnimos. La situacin es muy parecida con los servidores Jabber/XMPP. En los servidores pblicos, y en su ms pura esencia, las cuentas de usuario no son ms que unos repositorios de credenciales que los clientes usan para autentificarse con el servidor. Adems de estos datos bsicos, muchos servidores asocian otros datos a la cuenta de usuario como pueden ser el e-mail, el nombre completo del usuario y su telfono, as como otros datos que el servidor quiera recoger de sus usuarios. Adems muchos usuarios tambin almacenan vCards a su cuenta de usuario. Las vCards son como tarjetas de negocio, en formato XML, que contienen informacin de contacto sobre una persona. Los servidores tienen muchas formas de almacenar la informacin de un usuario. La forma de almacenar estos datos est fuera del alcance del protocolo Jabber/XMPP y por ello cada servidor lo realizar de la forma que mejor se adapte a sus necesidades. Una forma muy utilizada, y que tambin la utiliza el servidor de referencia de Jabber/XMPP (jabberd) es usar ficheros XML

31

con los datos de cada usuario dentro de un directorio. Otras implementaciones pueden ser por ejemplo usar una base de datos o hacer persistente los datos mediante tecnologas como J2EE o Hibernate. Si el servidor no tiene implementado este protocolo de registro se debern desarrollar utilidades para el tratado de las cuentas de usuario. Otros servidores tendrn implementado este protocolo y adems tendrn otras herramientas para el manejo de las cuentas de usuario. O este trabajo puede hacerse a mano sin ser automatizado como en jabberd que adems de implementar el protocolo, el administrador puede crear cuentas de usuario simplemente creando ficheros XML con el formato adecuado y dejndolos en la carpeta de spool correspondiente donde se encuentran el resto de los usuarios. Aunque el manejo y almacenamiento de las cuentas de usuario puede ser algo complicado, la implementacin del protocolo de registro no es as. El protocolo de registro normalmente suele ser junto con el de autentificacin el nico protocolo que un usuario sin autentificar puede usar de un servidor Jabber/XMPP despus de iniciar la conversacin con la etiqueta <stream:stream>. En general el protocolo implica una consulta get para comprobar el tipo de registro implementado en el servidor, y los datos necesarios para el registro, y un set para el registro en s, en el que se debern enviar al menos los datos obligatorios como son el nombre de usuario y la contrasea. Hacer la peticin get, antes de registrarse no es obligatorio, pero dar informacin al cliente de que campos son soportados por el servidor en el registro, ya que el envo de campos no implementados por el servidor no est implementado en el protocolo, y se desconoce su respuesta. El servidor normalmente borrar los campos no soportados o los almacenar aunque nunca los utilizar. En cualquiera de los casos el cliente estar malgastando ancho de banda. Por esa razn es recomendable que se pida al servidor que campos necesita antes de registrar a un usuario. La prueba de registro implica el envo de la etiqueta get en un mensaje vaco:
<iq type='get' id='register_get_id'> <query xmlns='jabber:iq:register'/> </iq>

El servidor responder con un paquete IQ de respuesta que contendr las etiquetas vacas de los campos que soporta, o un error IQ informando que no soporta el protocolo de registro. La respuesta tpica sera la siguiente:
<iq type='result' id='register_get_id'> <query xmlns='jabber:iq:register'> <username/> <password/>

32

<hash/> <email/> <phone/> </query> </iq>

El servidor puede indicar cero o ms etiquetas de registro como en este caso. Los clientes generalmente crearn un formulario con un campo de texto seguido tras una etiqueta que informar de lo que hay que rellenar en el campo de texto. Hay que fijarse que campos como <username>, <password> o <hash> son estndar y siempre pertenecern a la peticin. Y el cliente siempre los reconocer como campos especiales. El cliente utilizar la contrasea para generar los credenciales de autentificacin que van dentro de los campos <password>, <hash>, <sequence> y <token>. La aplicacin cliente coger la informacin que el usuario le proporcione y generar un paquete de registro que ser enviado al servidor:
<iq type='set' id='register_set_id'> <query xmlns='jabber:iq:register'> <username>Nombre</username> <password>Password</password> <email>Nombre@[Link]</email> <phone>94 444 55 66</phone> </query> </iq>

En el caso de que en la prueba del servidor, ste haya contestado que admite el campo hash significar que admite el protocolo de zero-knowledge authentification entonces el cliente deber generar los credenciales de los que se ha hablado anteriormente:
<iq type='set' id='register_set_id'> <query xmlns='jabber:iq:register'> <username>Nombre</username> <hash>23ea323be3231</hash> <sequence>100</sequence> <token>9823cd2323fa</token> <email>Nombre@[Link] </email> <phone>94 444 55 66</phone> </query> </iq>

Si todo ha ido correctamente el servidor crear la cuenta de usuario y devolver una respuesta vaca:
<iq type='result' id='register_set_id'/>

Si no es as, el servidor devolver un mensaje de error IQ normal indicando por qu se ha producido el fallo. Normalmente ser debido a que el nombre de usuario que se intenta registrar ya est usado en el servidor, o si el usuario estuviera intentando modificar algn dato de la cuenta de usuario sin autentificarse previamente tambin devolvera un mensaje de error. 33

34

6.2.

Authentication protocol (jabber:iq:auth)

El protocolo de autentificacin de Jabber/XMPP es, como el de registro, una extensin del protocolo IQ. Es uno de los protocolos nicamente dedicados a la seguridad en Jabber, permite a los usuarios demostrar a su servidor que son quien dicen ser, aunque muchas veces el cliente no tiene la certeza de que el servidor sea quien dice ser, ya que dentro de una red un cliente puede interceptar sus mensajes y engaarle, pero esto ya no es cosa del protocolo Jabber/XMPP, si no fallos que derivan directamente de las direcciones IP v.4. Este sistema de autentificacin pertenece al ncleo del protocolo Jabber, es decir, a los inicios del protocolo, desde que sali el estndar Jabber/XMPP la autentificacin se realiza mediante SASL, aunque siguen existiendo servidores que admiten este tipo de autentificacin. El sistema de autentificacin y acceso a un servidor es simple: los clientes no autentificados tienen una serie de permisos, y los clientes autentificados tienen un completo acceso al uso de todos los protocolos de Jabber/XMPP que estn implementados en el servidor del dominio al que pertenecen. Desafortunadamente, este simple modelo de autentificacin est muchas veces limitado. Por ejemplo en la actualidad no hay una forma estndar de restringir el acceso a los grupos de conversacin Adems si un administrador de un sistema Jabber/XMPP desea restringir los mensajes a ciertos dominios Jabber/XMPP, limitar el tamao de transferencias de ficheros, el tamao de los paquetes u otras funciones administrativas, se ver ante la ausencia en el protocolo Jabber/XMPP de estndares sobre este tipo de funciones administrativas, todo este tipo de tcnicas quedan de momento fuera del protocolo y debern ser diseados e implementados por el administrador del sistema y los desarrolladores del servidor. Otro problema es que Jabber/XMPP no distingue entre rangos o grupos de usuarios, todos los usuarios tienen segn el protocolo el mismo derecho a usar todos los protocolos implementados en el servidor, sin embargo esto debera ser diferente. Se estn juntando dos conceptos diferentes como son el de autentificacin y autorizacin, una persona autentificada no debera estar autorizada a hacer todo lo que deseara. Sin duda este aspecto se retomar cuando el protocolo est en plena madurez. Quitando estos pequeos inconvenientes que pueden ser solucionados por los desarrolladores aunque no estn tratados en el conjunto del protocolo Jabber/XMPP, el protocolo de autentificacin de Jabber/XMPP aporta garantas suficientes para cualquier sistema de MI y sus actividades. Adems el protocolo nos ofrece cuatro niveles diferentes de autentificacin: o o o o Anonymous. Plain. Digest. Zero-knowledge.

35

Como el protocolo de registro, el protocolo de autentificacin tambin consta de dos fases diferentes, una de consulta en la que el cliente podr conocer cules de los tres tipos de autentificacin que propone el estndar estn implementados en el servidor, que como resultado nos devolver datos de autentificacin usados para el mtodo zero-knowledge, si es que el servidor lo soporta. La segunda fase consiste en la autentificacin en s. El cliente enviar una peticin set que contendr los datos necesarios para la autentificacin segn el tipo de autentificacin que el usuario elija. La prueba de autentificacin utiliza una peticin get en la que se deber especificar el nombre del usuario que se pretende autentificar. El servidor retornar los mtodos de autentificacin disponibles para ese usuario en concreto y los campos que el usuario podra utilizar para autentificarse. Un ejemplo tpico de prueba de autentificacin sera el siguiente:
<iq type='get' id='auth_get_id'> <query xmlns='jabber:iq:auth'> <username>oscar</username> </query> </iq>

La presencia o ausencia de determinados campos en la contestacin del servidor indicar que tipos de autentificacin soporta el servidor:
<iq type='result' id='auth_get_id'> <query xmlns='jabber:iq:auth'> <username>oscar</username> <resource/> <password/> <digest/> <token>33ab323</token> <sequence>99</sequence> </query> </iq>

La presencia de <password> indica que admite la autentificacin en modo texto de la contrasea, es decir, autentificacin plain. El campo <digest> indica que admite la autentificacin tipo digest. Finalmente la presencia de <token> y de <sequence> conteniendo datos indica que es posible una autentificacin del tipo zero-knowledge. Es posible recibir un resultado que no contenga ninguno de esos campos, en tal caso, el servidor en cuestin slo soportara usuarios annimos, por lo tanto, sin autentificar. Una vez que el cliente ya conoce los diferentes mtodos con los que puede autentificarse deber seleccionar el ms adecuado segn su criterio. Es importante que slo se enven los campos de un tipo de autentificacin en la peticin set de autentificacin. El resultado del envo de mltiples tipos de autentificacin simultneos no est contemplado en el estndar de Jabber/XMPP. Sin embargo el protocolo de autentificacin de Jabber/XMPP no contempla la forma de salir del usuario en el que te has autentificado, para finalizar la sesin se deber enviar la etiqueta de cierre </stream:stream> para

36

cerrar la sesin con el servidor, y en el caso de querer conectarse como otro usuario diferentes se deber volver a conectar con el servidor para su posterior autentificacin.

6.2.1.

Anonymous Authentication

Si el servidor admite usuarios annimos bastar con el envo de la peticin set sin ningn otro tipo de datos:
<iq type='set' id='auth_set_id'> <query xmlns='jabber:iq:auth'/> </iq>

El servidor responder con un error si no soporta usuarios no autentificados. Pero si soporta usuarios annimos devolver como resultado del set un nombre aleatorio:
<iq type='result' id='auth_set_id'> <query xmlns='jabber:iq:auth'> <resource>nombreAleatorio</resource> </query> </iq>

El usuario podr entonces enviar mensajes, donde su Jabber ID estar formado por el nombre del servidor seguido del carcter / y del recurso aleatorio que ha devuelto en la autentificacin annima, es decir: Jabber ID: [Link]/nombreAleatorio

6.2.2.

Plain Authentication

Este tipo de autentificacin es el primero que provee de algn tipo de seguridad. Su principal ventaja es su extrema sencillez a la hora de su implementacin. Funciona enviando dentro del XML de autentificacin la contrasea en formato de texto sin codificar, del usuario a autentificar.
<iq type='set' id='auth_set_id'> <query xmlns='jabber:iq:auth'> <username>oscar</username> <resource>trabajo</resource> <password>pass</password> </query> </iq>

El principal problema de este tipo de autentificacin es que la contrasea es enviada de forma abierta al servidor. Es fcil que si alguien est escuchando la red pueda sacar la informacin de nuestro nombre de usuario y contrasea y utilizarla para suplantar nuestra identidad en el sistema Jabber.

37

6.2.3.

Digest Authentication

Para evitar el envo de contraseas en texto sin codificar, mediante este tipo de autentificacin el servidor enviar un identificador de sesin en el campo id junto con la etiqueta <stream:stream> de inicio de sesin. Para generar la autentificacin de tipo digest el cliente concatenar el identificador de la sesin con la contrasea del usuario. La cadena resultante ser codificada usando el algoritmo SHA-1. El texto en hexadecimal y minsculas ser enviado en la etiqueta <digest> en la peticin de autentificacin:
<iq type='set' id='auth_set_id'> <query xmlns='jabber:iq:auth'> <username>oscar</username> <resource>trabajo</resource> <digest>139ab93c13f31</digest> </query> </iq>

En java, por ejemplo, este algoritmo de autentificacin se implementara de una forma sencilla utilizando el paquete [Link]. El nico inconveniente de este tipo de autentificacin es que la contrasea del usuario debe ser enviada durante el protocolo de registro como texto sin codificar. Adems el servidor guardar la contrasea en formato de texto sin codificar. Un fallo en la seguridad del servidor puede poner en problemas la seguridad de las contraseas de sus usuarios. Sin embargo la contrasea slo viajar por la red empresarial o Internet durante el registro, luego ir siempre codificada. Todos los problemas sern solucionados con la siguiente forma de autentificacin.

6.2.4.

Zero-knowledge Authentication

Es el formato ms seguro y ms complicado soportado por los protocolos Jabber/XMPP, muchas veces lo podemos encontrar escrito como 0k. El mtodo de autentificacin 0k es complejo y su adopcin tanto en servidores como en clientes ralentizar el proceso de autentificacin. Este tipo de autentificacin ya no guarda la contrasea del usuario en el servidor. De hecho, la informacin que el servidor guarda son las credenciales que slo servirn para una nica autentificacin del cliente. El servidor ir creando nuevas credenciales de un solo uso. La tcnica para generarlas utiliza cuatro tipos de informacin: o La contrasea del usuario: usada por el cliente para generar llaves de tipo 0k. La contrasea es almacenada en el cliente y nunca ser 38

enviada al servidor. La llave ser creada con la combinacin de la contrasea del usuario y el token. o Token: informacin generada aleatoriamente usada para crear la llave de 0k. El token es almacenado en el servidor. Separando la contrasea y el token entre el cliente y el servidor respectivamente se consigue que la llave creada sea nica para el conjunto cliente/servidor. o Sequence: nmero que decrece automticamente indicando que llave del conjunto de llaves est siendo usada en el momento. o Hash: llave particular en el conjunto de llaves identificada por el nmero de secuencia explicado anteriormente. Inicialmente el cliente generar todas las piezas que se usarn en el protocolo de registro, para hacerlo el cliente: 1. Crear un mensaje de tipo digest con SHA-1 de la contrasea del usuario para crear el hashA. La salida se convertir a hexadecimal en minsculas. 2. Generar un token aleatorio. 3. Generar el digest de la combinacin de los resultados de los dos puntos anteriores para crear el has0 que ser pasado a hexadecimal en minsculas. 4. Selecciona arbitrariamente un nmero de secuencia. 5. Digest del hash-n para crear el hash-(n+1) y convertirlo en hexadecimal. As hasta generar la secuencia m que ser el nmero del paso 4. El cliente enva el token, la secuencia, y el hash al servidor en el protocolo de registro si ste soporta autentificacin 0k. Para autentificarse, el cliente seguir dos pasos. El primero consistir en enviar una prueba de autentificacin y el servidor devolver el token, y el nmero de secuencia menos uno. El cliente coge este token, y el nmero de secuencia y genera un nuevo hash(m-1). El cliente para ello sigue los mismos pasos que los explicados anteriormente excepto que utiliza el token y el nmero de secuencia dados, y se los enva al servidor. El servidor coge el hash-(m-1) y genera el hash m mediante digest. Compara el enviado por el cliente y el que ha generado l, si coinciden el usuario habr sido autentificado. Si no coinciden devolver un mensaje IQ de error. Si todo es correcto el servidor decrementa el nmero de secuencia y lo almacena. La prxima vez que el cliente se autentifique, el servidor enviar el token M-2 al cliente. El proceso continuar hasta que el nmero de secuencia llegue a cero. El cliente deber de volver a usar el protocolo de registro para actualizar el token y el nmero de secuencia antes de que ste llegue a cero.

39

Hay que fijarse que el servidor no puede predecir qu hash n-1 saldr del hash n. Es realmente una llave de un solo uso. Si alguien robara la llave y ve que funciona esa llave slo le servir para esa vez, porque no se podr volver a autentificar ya que no podr adivinar la siguiente llave para el siguiente nmero de secuencia. Este tipo de autentificacin tiene muchas ventajas: o Las contraseas nunca son enviadas por la red. o Las contraseas nunca son almacenadas en el servidor. o Las contraseas robadas dejan de ser vlidas tan pronto como son usadas. o La mayora del procesamiento es para el cliente, liberando al servidor que podra generar si no un cuello de botella en el sistema. La nica vulnerabilidad del sistema es la no actualizacin de los credenciales antes de que el nmero de secuencia llegue a cero. La actualizacin de los mismos slo es posible una vez el cliente se haya autentificado. Realmente sugerimos que nicamente los clientes autentificados con una conexin segura (SSL) puedan actualizar las credenciales, si no es as un atacante utilizando la tcnica de man in the middle podra enviar nuevos credenciales al servidor una vez que el usuario se haya autentificado robando la cuenta de usuario. Como puede verse la implantacin del sistema 0k conlleva un gran esfuerzo para los desarrolladores pero puede merecer la pena segn el sistema que se quiera implantar sobre Jabber/XMPP. Creemos que no tendra sentido implantarlo en una simple aplicacin de MI, pero s en otro tipo de aplicaciones que requieran este tipo de seguridad para sus conexiones Jabber/XMPP. Este protocolo fue adoptado por Jabber/XMPP recientemente, y esperemos que dentro de un tiempo todo haya avanzado lo suficiente para que no sea un gran gasto de procesamiento y que se aplique en cualquier tipo de aplicacin Jabber/XMPP.

40

6.3.

Roster Protocol (jabber:iq:roster)

Para no tener que enviar los cambios de presencia entre todos los usuarios del sistema Jabber/XMPP ha creado el concepto de suscripcin de presencia. Como su nombre indica, la suscripcin de presencia determina los suscriptores que recibirn las actualizaciones de presencia de cada usuario. Los suscriptores pedirn una suscripcin a un usuario, y el usuario aceptar o denegar dicha suscripcin. Cada usuario se suscribir a los usuarios que desee y podr aceptar que dichos usuarios u otros usuarios se suscriban a los cambios de su presencia. Para organizar y administrar las suscripciones de cada usuario, Jabber/XMPP ha definido unas estructuras de datos estndar conocidas como Jabber/XMPP roster. Jabber/XMPP roster no es mas que una lista de otros usuarios identificados por su Jabber ID. El protocolo de suscripcin de presencia permite a los usuarios suscribirse a la presencia de otros usuarios, sea cual sea su dominio de Jabber. Los servidores usan el protocolo de suscripcin de presencia para sincronizar los rosters para sus usuarios tanto fuera como dentro de su dominio. Los diferentes tipos de relaciones de suscripcin tratados por el roster son los siguientes: o to: el usuario est interesado en recibir las actualizaciones de presencia del suscriptor. o from: el suscriptor est interesado en recibir las actualizaciones de presencia del usuario. o both: el usuario y el suscriptor tienen un mutuo inters en recibir las presencias entre ellos. o none: ni el usuario ni el suscriptor tienen inters por recibir presencias entre ellos. Adems de la informacin bsica de suscripcin, el roster permite al usuario almacenar informacin estndar del interfaz de ese suscriptor. Esta informacin incluye un sobrenombre puesto por el usuario a su suscriptor y el grupo o grupos al que pertenece el suscriptor a la hora de mostrarlo en la interfaz. Una de las cosas ms importantes es que toda esta informacin est almacenada y administrada por el servidor. Esto simplifica notablemente la implementacin y permite al usuario tener disponible dicha informacin all donde se encuentre. Cualquier cambio realizado en el roster en uno de los clientes ser automticamente actualizado en los dems clientes iniciados con el mismo Jabber ID. El protocolo roster fue desarrollado para permitir a los clientes su administracin.

41

A pesar de la estrecha relacin entre el roster y la presencia, son conceptos diferentes. Digamos que el roster es todo el conjunto de contactos relacionados con nuestra cuenta Jabber. Adems podemos guardar datos de cada contacto como un sobrenombre puesto por el usuario o el grupo o grupos al que pertenece para poder as buscar todos los contactos de un grupo, y no tener que recorrernos todos los contactos. Como cada usuario tendr su propio roster, si enviamos una actualizacin de presencia al servidor, ste buscar en nuestro roster todos los contactos que tengan los tipos de suscripcin both o form para reenviarles slo a ellos nuestra presencia. Como todo se almacena en el servidor, el cliente comenzar nada ms autentificarse pidiendo todo el roster al servidor con un roster reset. Mostrar entonces todos los contactos del roster en la aplicacin. Si ms adelante el usuario desea hacer cambios en algn contacto del roster enviar una roster update al servidor y se quedar esperando un roster push del servidor para confirmar la actualizacin a todos los clientes abiertos con el mismo Jabber ID, ya que si uno de ellos realiza un cambio, ste se tiene que reflejar en el resto. Los cambios del roster pueden suceder en cualquier momento desde que un usuario se autentifica, por lo tanto los clientes deben estar preparados para recibir del servidor roster push y actualizar los contactos que muestran en ese momento. El servidor enviar un roster push cuando: o Una actualizacin del roster cambie los atributos del mismo, y se deba actualizar los clientes mostrados o alguno de sus atributos. o Cuando por algn cambio en el tipo de suscripcin de presencia se deba crear o borrar un contacto. Como se ha visto el protocolo de suscripcin de presencia tiene grandes efectos sobre el roster, tantos que una actualizacin del tipo de suscripcin puede hacer desaparecer de la pantalla del usuario un contacto, ya que si el contacto no desea ser visto por el usuario y enva una cancelacin de la suscripcin de presencia ponindola a none el usuario debe de dejar de ver el estado de ese contacto lo antes posible. Los clientes slo pueden modificar el apodo de sus contactos y el grupo o grupos a los que pertenecen mediante el protocolo roster. Adems, como hemos visto pueden influir en el roster mediante el protocolo de suscripcin de presencia. El diseo de las suscripciones de presencia y los roster de Jabber/XMPP facilitan el desarrollo de los clientes Jabber/XMPP, ya que los clientes no deben almacenar esos datos, ni tampoco se deben de preocupar de cmo modificarlos o administrarlos, lo nico que deben hacer es realizar peticiones al servidor y ser ste quien se encargue de su procesamiento. Adems el servidor se debe encargar de que cuando el usuario se desconecte o conecte todos sus suscriptores reciban una actualizacin de presencia.

42

Aun as los clientes son libres de enviar de por s actualizaciones de presencia a otros usuarios. Sin embargo si esto se realiza, el cliente deber gestionar que actualiza la presencia de todos sus contactos, mientras que si lo hace a travs del roster, slo le enviar la actualizacin de presencia al servidor y ser ste quien lo gestione. El protocolo roster es una extensin del protocolo IQ, existen tres tipos bsicos de protocolos roster: o Roster get: usado por los clientes para obtener una copia del roster almacenado en el servidor. o Roster update: usado por los clientes para actualizar el roster almacenado en el servidor. o Roster push: actualizaciones asncronas del roster que el servidor enva a los clientes. Vamos a ver mejor cada tipo del protocolo roster.

6.3.1.

Roster get

Permite a los clientes obtener una copia completa del roster almacenado en su servidor Jabber/XMPP. Para ello se debe enviar un mensaje IQ de tipo get vaco especificando el protocolo jabber:iq:roster.
<iq type='get' id='roster_get_id'> <query xmlns='jabber:iq:roster'/> </iq>

Y el servidor contestar con una copia completa del roster.

<iq type='result' id='roster_get_id'> <query xmlns='jabber:iq:roster'> <item jid='sub1ID' name='nickname1' subscription='both'> <group>Personal</group> <group>Trabajo</group> </item> <item jid='sub2ID' name='nickname2' subscription='from'> <group>Trabajo</group> <group>Familia</group> <group>Equipo de Futbol</group> </item> </query> </iq>

Hay que tener en cuenta que el paquete <query> puede tener cero o ms paquetes <item>. Cada paquete <item> representa una suscripcin de un contacto, y ese contacto pertenecer a cero o ms grupos, identificados por cero o ms paquetes <group>. La etiqueta name es opcional aunque

43

generalmente siempre se utiliza para que el cliente muestre un nombre en los contactos en lugar del Jabber ID del contacto.

6.3.2.

Roster update

Los clientes pueden modificar el roster enviando un paquete IQ de tipo set conteniendo dentro del paquete <query> el item a actualizar.
<iq type='set' id='roster_set_id'> <query xmlns='jabber:iq:roster'> <item jid='sub1ID' name='Pepe'> <group>Trabajo</group> <group>Familia</group> <group>Equipo de Baloncesto</group> </item> </query> </iq>

El servidor responder con un paquete IQ de tipo respuesta indicando que la actualizacin se ha realizado correctamente o un paquete IQ de error en caso contrario. El servidor enviar los cambios a todos los clientes autentificados usando el siguiente protocolo.

6.3.3.

Roster push

Es enviado por el servidor a todos los clientes que se han conectado con el mismo Jabber ID tras una modificacin en el roster por alguno de ellos o por la modificacin del tipo de suscripcin de presencia de alguno de los contactos. Son los nicos mensajes IQ que no obtienen respuesta, slo van del servidor a los clientes y stos no tienen que responder. El roster push para la actualizacin anterior sera la siguiente.
<iq type='set'> <query xmlns='jabber:iq:roster'> <item jid='sub1ID' name='Pepe' subscription='both'> <group>Trabajo</group> <group>Familia</group> <group>Equipo de Baloncesto</group> </item> </query> </iq>

Si un cliente borra su suscripcin del roster usando el protocolo de suscripcin, el roster item de esa suscripcin sera borrado del servidor. El servidor enviara un roster push a todos los clientes indicando lo acontecido con un mensaje IQ de tipo set y poniendo el atributo subscription con el valor remove. El cliente entonces borrara ese item de entre los contactos que est mostrando.

44

Por ejemplo si yo me desuscribo de sub1ID y el hace lo mismo conmigo yo recibira el siguiente roster push del servidor.
<iq type='set'> <query xmlns='jabber:iq:roster'> <item jid='sub1ID' subscription='remove'/> </query> </iq>

45

7. Autentificacin SASL
XMPP incluye autentificacin mediante SASL (Simple Authentication and Security Layer), como ya se ha comentado antes en los inicios del protocolo Jabber la autentificacin se realizaba mediante el protocolo jabber:iq:auth, pero hoy en da SASL es quien se lleva la palma. SASL provee a Jabber/XMPP de un mtodo generalizado para la autentificacin. Para ello se han aplicado ciertas normas en la autentificacin: o Si la autentificacin SASL se da entre dos servidores, la comunicacin no se establecer hasta que se aseguren de la autntica DNS del otro servidor, vase la comunicacin entre servidores (Server-to-Server) del siguiente apartado. o Si quien quiere autentificarse soporta SASL deber incluir el atributo version con el valor 1.0 por lo menos, en la cabecera del stream inicial. o Si el servidor soporta SASL deber informar de sus tipos de autentificaciones con la etiqueta <mechanisms/> en la contestacin de la etiqueta de inicio de sesin, si es que el cliente soporta la conexin SASL. o Durante la negociacin SASL, ninguno de los dos deber enviar algn carcter en blanco como separacin entre elementes, esta prohibicin ayuda a asegurar la precisin a nivel de byte. o Cualquier carcter XML contenido en los elementos XML deber estar codificado usando base64.

El proceso de autentificacin mediante SASL sera el siguiente: 1. La entidad que pida una autentificacin SASL deber incluir el atributo version el la etiqueta de inicio de sesin enviada al servidor con el valor 1.0 como mnimo. 2. Cuando el servidor recibe la etiqueta de inicio de sesin con el atributo version deber comunicar los tipos de autentificacin SASL que implementa, cada uno de ellos ir dentro de un hijo del tipo <mechanisms/>. 3. El cliente deber seleccionar uno de los mecanismos enviando el elemento <auth/> con un valor adecuado para el mecanismo de autentificacin SASL elegido. El elemento contendr caracteres XML (en la terminologa de SASL, la respuesta inicial initial response). Si el cliente debe responder con un elemento vaco responder con el carcter =, que indicar que la respuesta no contiene datos. 46

4. Si fuera necesario, el servidor enviar el elemento <challenge/> al cliente que contendr datos en formato XML, esto depender del tipo de autentificacin SASL que el cliente haya elegido. 5. El cliente responder al desafo enviando la etiqueta <response/> al servidor. 6. Si fuera necesario el servidor enviara ms elementos challenge y el cliente respondera a los mismos. Esta serie de challenge/response continuara hasta que ocurriera una de estas tres cosas: o Que el cliente que quera autentificarse aborte la autentificacin enviando la etiqueta <abort/> al servidor. En cuyo caso el servidor dejar al cliente enviar un nmero configurable de peticiones ms, normalmente dos, antes de cerrar la conexin TCP. As el cliente podr volver a autentificarse sin necesidad de reiniciar la sesin como pasaba con el protocolo Jabber original. o Que el servidor responda con la etiqueta <failure/>, con la que comunicara al cliente que la autentificacin ha fallado. Como en el caso anterior le dejar enviar un limitado nmero de peticiones ms para que si lo desea vuelva a intentarlo. o Que el servidor responda con la etiqueta <sucess/>, ocn la que comunicara al cliente que la autentificacin se ha realizado correctamente, y adems contendra datos en formato XML dependiendo del tipo de autentificacin SASL. Una vez realizada la autentificacin el cliente deber enviar una etiqueta vaca de inicio de sesin, sin necesidad de cerrar la sesin anterior, a la que contestar el servidor y comenzar la conexin. La autentificacin SASL puede generar diferentes errores: o <aborted/>: autentificacin abortada, explicada anteriormente. o <incorrect-encoding/>: los datos enviados por el cliente no pueden ser procesados por el servidor debido a que la codificacin base64 es incorrecta. o <invalid-authzid/>: el authzid dado por el cliente es invlido debido a que est mal formado o a que el cliente no tiene permisos. o <invalid-mechanism/>: el cliente tiene o solicita un mecanismo que no est implementado en el servidor. o <mechanism-too-weak>: el mecanismo est considerado como dbil por la poltica de seguridad del servidor.

47

o <not-authorized/>: la autentificacin ha fallado debido a que el cliente no tiene credenciales vlidos. o <temporary-auth-failure>: la autentificacin ha fallado debido a un error temporal del servidor. Veamos un ejemplo de autentificacin SASL entre un cliente y un servidor :

1. El cliente enva la etiqueta de inicio de sesin al servidor:

<stream:stream xmlns='jabber:client' xmlns:stream='[Link] to=[Link] version='1.0'>

2. El servidor responde al cliente con la etiqueta de inicio:

<stream:stream xmlns='jabber:client' xmlns:stream='[Link] id='c2s_234' from=[Link] version='1.0'>

3. El servidor informa al cliente de los mecanismos disponibles:

<stream:features> <mechanisms xmlns='urn:ietf:params:xml:ns:xmpp-sasl'> <mechanism>DIGEST-MD5</mechanism> <mechanism>PLAIN</mechanism> </mechanisms> </stream:features>

4. El cliente selecciona el mecanismo deseado:

<auth xmlns='urn:ietf:params:xml:ns:xmpp-sasl' mechanism='DIGEST-MD5'/>

5. El servidor enva el challenge al cliente en base64:

<challenge xmlns='urn:ietf:params:xml:ns:xmpp-sasl'> cmVhbG09InNvbWVyZWFsbSIsbm9uY2U9Ik9BNk1HOXRFUUdtMmhoIixxb3A9ImF1 dGgi LGNoYXJzZXQ9dXRmLTgsYWxnb3JpdGhtPW1kNS1zZXNzCg== </challenge>

El challenge decodificado es:

realm="somerealm",nonce="OA6MG9tEQGm2hh",\ qop="auth",charset=utf-8,algorithm=md5-sess

48

Aunque el servidor podra haber respondido con un error:

<failure xmlns='urn:ietf:params:xml:ns:xmpp-sasl'> <incorrect-encoding/> </failure> </stream:stream>

6. El cliente enva la respuesta en base64:

<response xmlns='urn:ietf:params:xml:ns:xmpp-sasl'> dXNlcm5hbWU9InNvbWVub2RlIixyZWFsbT0ic29tZXJlYWxtIixub25jZT0i T0E2TUc5dEVRR20yaGgiLGNub25jZT0iT0E2TUhYaDZWcVRyUmsiLG5jPTAw MDAwMDAxLHFvcD1hdXRoLGRpZ2VzdC11cmk9InhtcHAvZXhhbXBsZS5jb20i LHJlc3BvbnNlPWQzODhkYWQ5MGQ0YmJkNzYwYTE1MjMyMWYyMTQzYWY3LGNo YXJzZXQ9dXRmLTgK </response>

La respuesta decodificada es:

username="somenode",realm="somerealm",\ nonce="OA6MG9tEQGm2hh",cnonce="OA6MHXh6VqTrRk",\ nc=00000001,qop=auth,digest-uri="xmpp/[Link]",\ response=d388dad90d4bbd760a152321f2143af7,charset=utf-8

7. El servidor enva otro challenge codificado al cliente:

<challenge xmlns='urn:ietf:params:xml:ns:xmpp-sasl'> cnNwYXV0aD1lYTQwZjYwMzM1YzQyN2I1NTI3Yjg0ZGJhYmNkZmZmZAo= </challenge>

El challenge decodificado es:

rspauth=ea40f60335c427b5527b84dbabcdfffd

El servidor tambin podra haber respondido con un error:

<failure xmlns='urn:ietf:params:xml:ns:xmpp-sasl'> <temporary-auth-failure/> </failure> </stream:stream>

8. El cliente responde:
<response xmlns='urn:ietf:params:xml:ns:xmpp-sasl'/>

9. El servidor le dice al cliente que la autentificacin ha sido correcta:

<success xmlns='urn:ietf:params:xml:ns:xmpp-sasl'/>

El servidor podra haber respondido con error:

<failure xmlns='urn:ietf:params:xml:ns:xmpp-sasl'> <temporary-auth-failure/> </failure>

49

</stream:stream>

10. El cliente enva una nueva etiqueta de inicio de sesin:

<stream:stream xmlns='jabber:client' xmlns:stream='[Link] to=[Link] version='1.0'>

11. El servidor responde al cliente con una cabecera de sesin con ms opciones (o si no con la etiqueta features vaca):
<stream:stream xmlns='jabber:client' xmlns:stream='[Link] id='c2s_345' from=[Link] version='1.0'> <stream:features> <bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'/> <session xmlns='urn:ietf:params:xml:ns:xmpp-session'/> </stream:features>

50

8. Comunicacin Server-to-Server (jabber:server)

Hasta ahora slo se han mencionado las comunicaciones entre servidores sin llegar a profundizar en cmo propone el protocolo Jabber/XMPP su utilizacin. El conjunto de protocolos que las implementa no se deberan implementar en un servidor privado que una intranet empresarial, si lo que realmente se pretende es que los usuarios del sistema Jabber/XMPP nicamente puedan hablar con sus compaeros, es decir, con los dems clientes de su dominio. En una red empresarial con similares propsitos, pero con ms de un dominio de redes Jabber/XMPP de la empresa, habra que implementar este protocolo pero siempre habra que amoldarlo para que el servidor hiciera un buen uso del mismo y slo se conectara con otros servidores de la empresa, y no con servidores pblicos en donde puedan tener contactos los trabajadores de la empresa. Las comunicaciones entre clientes y servidores se basan siempre en el conjunto de protocolos jabber:client, mientras que este tipo de comunicaciones entre servidores se basarn en el conjunto jabber:server. Existen dos grandes diferencias entre las comunicaciones entre clientes y servidores y las comunicaciones entre servidores. Mientras que en las primeras la comunicacin es bidireccional las comunicaciones entre servidores son unidireccionales, es decir, aunque en realidad se establezcan conexiones mediante sockets bidireccionales este tipo de comunicaciones slo permiten enviar paquetes al servidor que ha iniciado la conversacin. El servidor receptor slo enviar de vuelta sus paquetes XML y mensajes de error. Si los servidores necesitaran enviar paquetes en ambas direcciones deberan crear dos conexiones diferentes. La segunda gran diferencia es que en las comunicaciones entre servidores los campos to y from deben estar perfectamente rellenados, ya que el servidor destino no conoce al cliente que ha enviado ese paquete al servidor que se lo est mandando, por lo tanto ser el servidor del dominio del cliente el responsable de rellenar cualquiera de estos campos. As, si el usuario conectado al servidor del dominio [Link] quisiera enviar un mensaje al usuario b del dominio Jabber/XMPP [Link] el mensaje original del cliente podra ser:
<message to='b@[Link]'> <body>Aupa!</body> </message>

El servidor [Link] recibe el mensaje, y lo edita para agregar el Jabber ID del emisor para poder conectarse con el servidor [Link] y podrselo enviar.

51

<message to='b@[Link]' from='a@[Link]'> <body>Aupa!</body> </message>

El servidor [Link] recibe el mensaje, encuentra al usuario b en lnea y depende de la implementacin del servidor podra volver a modificar el mensaje para quitarle el destinatario y ahorrar ancho de banda en el envo del mensaje:
<message from='a@[Link]'> <body>howdy</body> </message>

Cuando un servidor Jabber/XMPP acta en representacin de cualquiera de sus usuarios en una conexin S2S la seguridad en la conexin es algo muy importante. Cualquier servidor podra usurpar la identidad de un servidor local y hacerse con los mensajes de todos los usuarios que pertenezcan al dominio que estara usurpando en una red. Por ello existe la necesidad de que exista un protocolo de autentificacin tambin en las conexiones entre servidores S2S.

8.1.

Dialback authentication

La autentificacin entre servidores Jabber/XMPP es mucho ms complicada que entre los clientes y su servidor. En las autentificaciones entre un cliente y su servidor, slo los clientes con cuenta de usuario en ese servidor pueden acceder a autentificarse. Sin embargo en las conexiones S2S, los servidores Jabber/XMPP van a tener que autentificarse muchas veces con servidores con los que nunca han tenido un contacto y que no conocen. Adems, como el nmero de servidores Jabber/XMPP podra llegar a ser potencialmente grande, los servidores no pueden tener una cuenta para cada uno de los otros servidores. Este protocolo ha sido creado para crear un simple mecanismo de autentificacin para asegurarse de que cada servidor es quien dice ser, sin conocerlo previamente. Para ello el servidor que se quiere autentificar enva una clave al servidor en el que se quiere autentificar, ste para comprobar que el servidor que desea autentificarse es quien dice ser se conectar al dominio del servidor que dice ser y lo confirmar con la clave que ha recibido, supuestamente de ese mismo servidor. Si es as el servidor le enviar una contestacin informando que todo es correcto y que est autentificado, y este a su vez le enviar una contestacin al servidor que est autentificndose con l, aceptando su conexin. Esto es igual que en la vida real cuando una persona quiere identificar a un agente, si nos dice su nombre y nmero de placa y se lo preguntamos a su central a travs de su radio, esto no sera seguro porque si no fuera realmente un agente podramos estar hablando con un amigo suyo, sin embargo si llamamos a la central desde nuestro telfono mvil y nos lo confirman sabemos que quien nos lo est confirmando es realmente alguien desde la central.

52

En el protocolo se confa en el servidor de DNS, que ser quien nos va a decir la direccin real de ese servidor, y la utilizaremos para preguntarle si el se est intentando autentificar con nosotros o ha sido un impostor. Aun as este protocolo no es del todo seguro ya que la persona que intentara suplantar a otro servidor podra atacar al servidor de DNS para as registrar su IP en lugar de la del servidor real del domino, o incluso suplantar al DNS con tcnicas de Man in de Middle. La autentificacin entre el servidor [Link] y el servidor [Link] sera de la siguiente forma, [Link] se conectara a [Link] enviando la etiqueta de inicio de sesin e informando de que soporta la extensin jabber:server:dialback de autentificacin:
<stream:stream xmlns:stream='[Link] xmlns='jabber:server' to='[Link]' from='[Link]' xmlns:db='jabber:server:dialback'>

El servidor [Link] responde con la etiqueta de inicio de sesin, informando que l tambin soporta la autentificacin dialback y asigna un identificador a la sesin:
<stream:stream xmlns:stream='[Link] xmlns='jabber:server' to='[Link]' from='[Link]' xmlns:db='jabber:server:dialback' id='4208ab093e'>

As, [Link] enviar el mensaje con la clave de autentificacin como respuesta ya que ambos servidores implementan el protocolo:
<db:result to='[Link]' from='[Link]'>0283cd322312</db:result>

Con esta clave [Link] ya puede iniciar el protocolo de autentificacin y as deber buscar a [Link] en su servidor de DNS y conectarse a la direccin que ste le indique, para as iniciar la conversacin con el [Link] real:
<stream:stream xmlns:stream='[Link] xmlns='jabber:server' to='[Link]' from='[Link]' xmlns:db='jabber:server:dialback'>

El servidor [Link] soporta el protocolo de autentificacin por lo que responder con la etiqueta de comienzo de sesin y asignar un identificador para la sesin:
<stream:stream xmlns:stream='[Link] xmlns='jabber:server' to='[Link]' from='[Link]' xmlns:db='jabber:server:dialback'

53

id='403a33b093e'>

El servidor [Link] proceder a enviar la clave que recibi del supuesto [Link]:
<db:verify to='[Link]' from='[Link]' id='5423ef'> 0283cd322312 </db:verify>

El servidor [Link] determinar si existe una sesin abierta con [Link] y si la clave es correcta. Si es as, devolver la confirmacin a [Link]:
<db:result to='[Link]' from='[Link]' type='valid' id='5423ef'/>

El servidor [Link] enviar la confirmacin de autentificacin a la primera sesin que haba iniciado [Link] para autentificarse, por lo que la conexin se podr realizar y [Link] quedara as autentificado.
<db:result to='[Link]' from='[Link]' type='valid'/>

Si [Link] no reconocera la clave respondera a [Link] con una autentificacin incorrecta:

<db:result to='[Link]' from='[Link]' type='invalid' id='5423ef'/>

Y ste a su vez no aceptara la conexin inicial de [Link] ya que sera un impostor:

<db:result to='[Link]' from='[Link]' type='invalid'/>

La clave y su formato no estn especificados en las especificaciones del protocolo Jabber/XMPP. El servidor de referencia jabberd utiliza una codificacin SHA-1 de tipo digest de partes de los nombres de los servidores para generar y verificar este tipo de claves. As pues cada servidor podra tener una forma de generar este tipo de claves, pero la autentificacin sera correcta entre dos servidores que implementaran diferentes tipos de contraseas, ya que quien la genera y la confirma es el mismo servidor, y no importa como se haga.

54

9. Transporte entre Jabber/XMPP y otros servidores de MI

Debido a que Jabber/XMPP es un protocolo libre basado en el paso de paquetes en formato XML los sistemas Jabber/XMPP estn preparados para el uso como un sistema genrico de transporte de MI. Su simple diseo ha sido explotado por servidores Jabber/XMPP para conectarse con otros sistemas de MI como pueden ser el MSN Messenger y Yahoo! Messenger. El servidor Jabber/XMPP de referencia jabberd utiliza mdulos llamados transports que proveen un puente entre Jabber/XMPP y los dems sistemas de MI. Los transportes tratan a cada sistema de MI propietario como un dominio Jabber/XMPP con sus propios clientes identificndolos por su Jabber ID, que en realidad sera el nombre del usuario en el sistema externo. Al enviar un mensaje Jabber/XMPP a uno de esos mdulos esos Jabber IDs especiales hacen que sean transportados por el mdulo de transporte. Los mdulos de transporte conectan con el sistema de MI correspondiente y actan como clientes de ese servidor para intercambiar mensajes y presencia entre los dos sistemas. Por ejemplo, si se enva un mensaje a usuario@[Link] el servidor reconocer que [Link] es un usuario de otro sistema y se lo enviar al mdulo de transporte para que procese el paquete. El transporte iniciar la sesin en la red MSN Messenger y enviar el mensaje al interesado. Cada transporte deber parsear los mensajes Jabber/XMPP a mensajes con el formato del sistema de MI correspondiente. En los casos en que el sistema est bien documentado como puede ser el caso de IRC esto es algo sencillo y ya est realizndose sin ningn problema. El problema radica en los sistemas de MI propietarios como el MSN Messenger a los que este intercambio de mensajes no les conviene para mantener atados a sus clientes, por lo que tratan de cambiar el protocolo de manera regular para as tener que volver a realizar trabajos de ingeniera inversa los desarrolladores de los mdulos de transporte de cada servidor para poder adaptarlos a los cambios y que sigan funcionando correctamente.

55

10. Chatbots
Un chatbot es una aplicacin que autnomamente se comporta como otro usuario del sistema Jabber/XMPP. Cuando un usuario enva mensajes a un chatbot, ste automticamente genera sus propias respuestas. Los desarrolladores crean chatbots para resolver muy diversas necesidades, algunas son para mero ocio como pueden ser los chatbot que cuentan chistes. Pero sin embargo los chatbot pueden dar servicios mucho ms tiles como noticias meteorolgicas. Otros proveen de un traductor a los clientes, que envan mensajes en su idioma y el chatbot responde con las traducciones. As los usuarios pueden ir traduciendo la conversacin que estn estableciendo con otra persona que habla un idioma que no conocen. Los chatbots amplan las posibilidades de Jabber/XMPP hasta lmites insospechados, y son simples programas automatizados que hacen uso del protocolo nativo de Jabber/XMPP, sin necesidad de ningn otro cambio en el protocolo para sus actuaciones. Esta es una grandeza de Jabber/XMPP, de la que ningn otro sistema de MI puede presumir. Por lo general no tienen interfaz, simplemente se comunican con otros clientes que reclaman sus servicios va Jabber/XMPP. Estos programas pueden utilizarse adems como: o Soporte al consumidor: los chatbots pueden resolver dudas y problemas frecuentes en muchos mbitos comerciales, dando una respuesta rpida y eficaz a problemas usuales y catalogados por el proveedor. o Servicios de informacin: pueden proveer de informacin a otros usuarios. La informacin puede ser de muchos tipos como alertas del tiempo, ofertas comerciales, noticias o Servicios de bsqueda: estos servicios pueden ser del tipo de los buscadores de Internet habituales como google, guas telefnicas, bases de datos corporativas, diccionarios, traductores, bsquedas de artculos Como puede observarse nos ofrecen muy tiles y variados servicios que pueden llegar a convertirse en herramientas imprescindibles para los usuarios del sistema.

56

11. Jabber/XMPP como middleware

Jabber/XMPP puede verse como un desafortunado competidor de otros sistemas MOM. Sin embargo, los sistemas Jabber/XMPP pueden tener sus propios beneficios respecto a los tradicionales sistemas MOM, como pueden ser: o Econmico: las empresas pueden ver una solucin econmica en Jabber/XMPP para el paso de mensajes entre sus aplicaciones. Especialmente para aplicaciones que no sean criticas. o XML: como Jabber/XMPP est basado en XML es un maravilloso middleware para infraestructuras basadas en XML. o Abierto: el protocolo Jabber/XMPP y muchas de sus implementaciones son abiertas. Los beneficios del open-software estn perfectamente desarrollados en [Link]. o Simple: tanto las grandes como las pequeas empresas pueden entender y usar fcilmente Jabber/XMPP con un corto aprendizaje. o Ligero: Jabber/XMPP es un protocolo ligero en una red comparado con sus competidores. As el software que lo implementa es compacto y eficiente. El uso de Jabber/XMPP como MOM es una cuestin abierta en la comunidad Jabber/XMPP. Existen dos grupos en [Link]: JAM y Jabber/XMPP RPC. Ambos estn interesados en la integracin de Jabber/XMPP como middleware. Los desarrolladores de Java estn interesados en la integracin con JMS de Jabber/XMPP para su uso como middleware. Adems Jabber/XMPP sera un middleware excelente entre las tecnologas Microsoft .NET y los servidores J2EE de Java.

57

12. Sitios de inters

o JabberEs, comunidad hispana de Jabber: [Link] o Jabber Community: [Link] o Jabber Inc.: [Link] o Jabber Powered: [Link]

58

13. Agradecimientos
La realizacin de este documento ha sido posible gracias a la inestimable colaboracin de Lus Peralta que ha colaborado con entusiasmo en las tareas de revisin y correccin del manual. Tengo que agradecer tambin la colaboracin de Badlop en las tareas de revisin. Tengo que agradecer tambin a Natalia Vicandi su esfuerzo por animarme siempre a conseguir lo que me propongo. Tambin la gratificante ayuda de mis compaeros Oihane Mndez, Itxaso Dieguez e Iaki Larraaga. Adems agradecer los sabios consejos de Javier Vicente y Amaia Mndez.

59