Messaging and Directory Server software used around the world in the Government, Military, Aviation and Commercial sectors.

isode.com / whitepapers /

XMPP, M-Link and Directory

Intoduction

Isode provides both directory and XMPP server products, and the approach for M-Link (Isode’s XMPP Server) and associated management tools is to make maximum use of directory. This paper describes how M-Link makes use of directory, and explains why this close integration of XMPP and directory is beneficial.

M-Link and Directory

Isode's standard approach to M-Link configuration is shown above. The key architectural decision is that all configuration, user and authentication information is held in the directory and managed within the directory. Isode's configuration and authentication management tools operate on the directory. This gives a number of benefits, including:

• Decoupling of the management allows for flexible deployment.
• User information held in the directory can be shared with other applications.
• Applications using the directory can have common authentication (e.g., same username password for each application) and common authentication management.

The Isode White Paper Isode Management Architecture: Client/Server and Directory discusses this architectural approach in more detail.

Isode also provides a configuration option allowing for configuration data to be held in an XML file, which may be preferable in some situations, such as a small standalone server. Most deployments are expected to use directory based configuration.

An alternate architecture used by some products is shown below.

Here the XMPP server has a configuration database, with direct management of that configuration. There is also an option to connect to an external directory. The problems with this approach include:

• Directory is typically used only for some limited types of authentication.
• Where further information can be taken from the directory, there is potential conflict and inconsistency between the directory and configuration database.
• There is no mechanism for changes to move from the XMPP components to the directory, which makes information sharing with other applications harder.

User and Configuration Information

The directory enables use of Web based and GUI configuration and management tools. Three of Isode’s tools are particularly usefull for XMPP management:

• Internet Messaging Administration (IMA) is a Web Application that enables M-Link server configuration and user administration. It allows common administration of XMPP and Internet Email setups, and allows for delegated administration. Details on IMA are here.
• Personal Information Administration (PIA) allows users to change their personal preferences, and change passwords, including UI support for password policy capabilities such as password ageing. Details on PIA are here.
• Sodium is a secure directory administration GUI. It can be used to directly manage the M-Link server configuration, which is a simple option for a deployment that does not use Isode Internet Messaging. It can also be used to manage user entries in the directory that are used by M-Link. Details on Sodium are here.

An alternate approach will be suitable for ISPs and Service providers that have their own provisioning systems. Here, user information will be managed as a part of a provisioning system, and a copy can be maintained in the Directory for use by the XMPP system.

User Authentication and Authorization

The directory plays an important role in user authentication and authorization. For password based authentication, the username (Jabber ID or JID) and password are held in the directory. The JID will typically be the same as the user’s email address, and a single attribute may be used for both functions. Isode's Directory Server, M-Vault, can be used for password management and to enforces password policies.

XMPP uses authentication based on Simple Authentication and Security Layer (SASL) that enables support of both plain text mechanisms, and approaches such as DIGEST-MD5, that avoid sending plain text passwords. Isode's SASL implementation is closely integrated with M-Vault, and enables use of a wide selection of SASL mechanisms. Many XMPP servers integrate with directories in a way that only supports mechanisms that transfer passwords in the clear.

M-Link also supports strong authentication using the PKI mechanisms associated with TLS, and integrated at the application level using SASL EXTERNAL. The directory may be used to support this authentication, for path discovery (certificate retrieval) and CRL (Certificate Revocation List) checking. Directory is also used with strong authentication to provide an (implicit) authorization. M-Link will only allow users to connect if they are configured in the directory.

Profiles and Directory

XMPP users can have structured information stored in their XMPP server, as illustrated above (screenshot taken from the Pandion XMPP Client), that is made available to other XMPP users. This is the user profile. In many systems, users will manage their own information in the XMPP service, and this information will be available to those with whom they communicate.

There is significant overlap in functionality with capabilities typically provided by a directory service, and a number of things need to be considered:

1. Duplication of information can lead to errors and waste of administrative effort.
2. What information, if any, should be controlled by the user? In a secure environment, central control of information that is made available is likely to be important.
3. What directory-type information should be made available by XMPP?
4. XMPP has a “user administered” data model, whereas directory has a model that is based around control by central administration, but does allow for user updates.

Operational Model

Isode's model for relationship between XMPP profiles and the directory is shown above. Users are managed in the directory (as a directory entry for each user), and this is the location for user information. From a directory standpoint, information in a user’s directory entry may be centrally managed (e.g., using IMA) or managed by the end user in the directory (e.g., using PIA).

M-Link will obtain user and profile information from the directory, providing core user identity information for authentication and a configurable set of attributes used in the profile. Users and primary user information are managed in the directory.

The model also allows information to flow from XMPP to the directory, so that when the user changes profile information, this is updated in the directory. M-Link allows the following options that can be selected independently for each profile attribute type:

1. No updates allowed. This is the centralized model, where profile information is taken from the directory. In this model, M-Link does not permit the user to make changes to the attribute, and from the user perspective the profile attribute is read only.
2. Updates are permitted. When the user changes an attribute, this update is reflected back to the directory, and so will be shared with other directory applications. This in effect allows the XMPP client to provide end user update to attributes in the directory. Updates are likely to be allowed only for attributes not considered to be under central control, such as mobile telephone number.
3. Static. Here a fixed value is configured for an attribute for all users. This might be done for the company name in a corporate XMPP server.
4. Local. Here the information is help in the XMPP server and not in the directory. Users can set and update the value by XMPP, and this is not sent to the directory. This might be appropriate for a field such as nickname.

Information Formats

The details of implementing XMPP profile support in the directory require mapping of information between the user’s directory entry and the user’s profile. M-Link supports XEP-0154 "User Profile", which is the "standards track" XMPP profile definition. XEP-0154 is still evolving as a specification, and Isode will continue to work closely with this effort. XEP-0154 defines mappings between many profile elements and LDAP attributes. Isode defines a configurable mapping between each profile attribute and LDAP, Local or Static values. This defaults to the mapping defined in XEP-0154 for all LDAP attributes, and Local storage for attributes without no LDAP mapping defined in XEP-0154, so should not normally need changing.

Unfortunately, no deployed XMPP clients use XEP-0154, although this is expected to change. The widely deployed profile format is XEP-0054 "vcard-temp", which the XMPP Standards Foundation regards as historical. In order to support XEP-0054's vCard-based profiles, M-Link includes mapping between the vCard and XEP-0154 information models, as defined within XEP-0154.

Rosters

An XMPP Roster, sometimes referred to informally as a “buddy list” is maintained by every user in the user’s XMPP server, as a list of “contacts”, providing information on availability and other status. There are two ways that the directory can be used to support rosters.

Roster Pre-population

A roster is built up manually by a user, making a bilateral agreement with each peer that they want to communicate using XMPP. In general this is a sensible and practical approach. Where there is a group of users that communicate regularly (e.g., members of a department in a company), manually setting up links between every user is a rather tedious process.

Roster pre-population works by defining a group within the directory. The XMPP server is configured to support a set of groups, and will pre-populate the roster for each member of the group with all of the other group members. It will also make use of the ability to name groups within a roster, and use a name configured for the group. The effect for a user would be to find on initial startup one or more roster groups, such as "sales" or "engineering". This will be convenient in many situations, and will automatically update as group membership changes. Communication within the roster group can be enhanced by the ability of some XMPP clients to send a message to all members of the group.

Static Roster Configuration

Rosters hold highly dynamic information about a user’s status, known as presence information. Managing and distributing updates to presence status is a central function of an XMPP server, and needs to be done very efficiently. M-Link maintains roster information internally, and it would be inefficient to store (rapidly changing) presence status externally.

Although presence can change rapidly, it is usual that roster membership is relatively static. It can therefore make sense to hold static roster information in the directory. The main benefit of this is sharing with other applications. A user’s roster is essentially a list of the user’s friends or contacts. By putting this list into the directory, it can be shared with other applications, such as an email address book.

Multi-User Chat

M-Link supports two modes of multi-user chat (MUC), and a deployment may choose to use one or both:

1. Temporary. MUC rooms are created on demand, so that if a user attempts to join a room that does not exist, they will be asked to configure it, and then others may join. The room will be destroyed when the last person leaves, or if the creator destroys it. Rooms may be configured via XMPP, but this configuration must be reentered every time the room is (re)created.
2. Persistent. Here the configuration of the room will be held in the directory, and the room will persist when empty. Two mechanisms can be used to create, configure, and destroy managed rooms:
   • XMPP Protocol, so that rooms are managed by XMPP.
   • Web Management of the directory, so that rooms and room creation are managed by administration of the directory.

M-Link Feature Support

This white paper has looked at use of directory. Some of these features are supported by M-Link. This section sets out M-Link support of directory related features:

Features	M-Link Support
Server Configuration	Supported
User Configuration	Supported
Password Based Authentication (including SASL mechanisms plain text and password confidentiality)	Supported
Strong Authentication	Supported
Get Profiles	Supported
Update Profile in directory	Supported
Roster pre-population	Planned
Persistent MUC room configuration	Planned
Static roster configuration	Planned

Conclusions

This paper has shown how XMPP and Directory can co-exist and that there are significant benefits associated with the strong use of directory in an XMPP service. Most of the product features necessary to take advantage of these benefits are already included in Isode's XMPP server, M-Link. Support for the others is planned.

More information on M-Link is available and the product is available for evaluation.