Summary

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 effective 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.

Creative Commons License

User and Configuration Information

The primary role of directory in an M-Link configuration is to store information on users, and in particular XMPP client address (JID) and authentication information. Directory is a natural repository for this information and holding this information in a directory enables effective sharing with white pages services and other applications.

Storing account information in the directory enables use of Web based and GUI configuration and management tools. Three of Isode’s tools are useful for managing user accounts in the directory:

  • 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 organizations that have their own provisioning systems. Here, user information will be managed as a part of a provisioning system, and the information will be maintained in the Directory, and the XMPP system will be able to make use of it.

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, or a separate attribute for the JID may be used. 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. In particular SCRAM is supported by M-Link, which is a new secure password system that is preferred for XMPP. For more information see [SCRAM: A New Protocol for Password Authentication].

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.

In addition directory is used to hold User Security Clearances. When Access Control is performed based on Security Labels, Security Clearance information is obtained from the directory. Further information is provided in [Using Security Labels to Control Message Flow in XMPP Services].

As well as M-Vault, M-Link can work with any LDAP directory server and also with Microsoft Active Directory. M-Link management tools provide options to make setup with Active Directory straightforward.

Profiles and Directory

 

 

XMPP users can have structured information stored in their XMPP server, as illustrated above (screenshot taken from the Swift 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,

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.

Groups

M-Link’s second type of use of directory is in support of Groups. M-Link Console can be used to configure groups manually or by reference to the directory in two ways:

  1. By reference to a group configured in the directory using the LDAP and X.500 “Group of Names” attribute. For Active Directory this mechanism is often referred to as “AD Groups”.
  2. By definition of an LDAP search. This can be helpful for identifying a set of users who can be distinguished by a attribute or location in the directory information tree.

Groups are used by M-Link as a part of Multi-User Chat access control and for roster pre-population.

Roster Pre-Population

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.

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, as described above. 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 start-up 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.

M-Link Feature Support

This whitepaper has looked at use of directory. All of the features described are supported by M-Link.

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.