Last Modified 2009-02-27 by Guest

Using external groupware (PIM) clients with Horde

There are several ways to access Horde applications or backends with external clients. These options can be summerized into two groups. Either both Horde and the external applications access the same shared backends as clients. Alternatively Horde can act as a backend server itself, that can be used by external clients.

Shared backends

Kolab server

A Kolab server is probably the most complete groupware solution with a shared backend server. Kolab is basically a stack of proven open source server systems that build a complete groupware server including web based management and wide range of supported clients. Horde is the officially supported browser frontend for Kolab and supports all groupware features. There exist several clients for various platforms with native Kolab support, as well as connectors for existing groupware clients like Outlook or Thunderbird.

Homebrew servers

Kolab is probably the most comfortable way to install a groupware server for Horde. But if you already have some servers running that support open standards, chances are that you can access them with Horde applications. Horde applications support a wide range of protocols like IMAP, LDAP, IMSP and SQL. Due to the modular, driver-based architecture of the Horde Framework, you can even write your own drivers for backends that are currently not yet supported. Using Kronolith as frontend for a CalDAV server would be such possible driver.

Horde as a backend


SyncML is not really an access protocol, but a synchronization protocol. SyncML is already built into many mobile devices like mobile phones, and there exist many clients for mobile devices and desktop applications, most notably by Funambol and Synthesis. SyncML not used to access the live groupware data from the clients and manipulate them directly on the client, but to keep several copies of the same data synchronized with a push on a button.


Horde has a basic WebDAV interface that can be accessed by external clients like Thunderbird, Kontact, or Apple iCal. This interface is going to be the basis for more advanced GroupDAV and/or CalDAV interfaces. These are standards which allow more complex access to groupware data and scale better than plain WebDAV. Even in older versions of Kronolith and Nag exist HTTP interfaces with can be used by WebDAV compatible clients to connect to calendars and task lists, though limited to read-only access.


Several generic RPC interfaces exist in Horde, at the time of this writing XML-RPC, SOAP, and JSON. These can be used to access the external API of Horde and its applications and are rather targeted at developers. But there exists a wrapper around the XML-RPC interface that is compatible to the RPC interface of phpGroupWare/eGroupWare. At least one client (Kontact) supports this interface. It hasn't been tested much though.

Of course you can combine any of the scenarios mentioned here. You could use Horde as a frontend for a Kolab server and as a SyncML server for your PDAs and phones at the same time. Or you can use the Kolab server as a groupware backend, but add more address books from your company's LDAP or Active Directory servers, etc.

Authentication Caveats

The above methods all use the rpc.php entry point to horde, which in most cases uses basic HTTP authentication to authorize access. This may not work out of the box when PHP is run in CGI mode. Please see HTTPAuthHowTo for a workaround.

If you have configured Horde to use Shibboleth as an authentication method then the RPC interface will fail as Horde will have no means to authenticate the user with the supplied HTTP authentication credentials (no _authenticate method in the Shibboleth driver). Shibboleth is designed for web browser based applications and hides the authentication part from Horde, providing just a trusted session and attribute data about the externally authenticated user.