6.0.0-git
2024-03-19
Last Modified 2011-04-26 by Ben Klang

Authentication

How authentication works in Horde

If Horde is used on the browser, the user logs in usually on a form. The username-password combination is passed by the Horde authentication driver to the authentication backend. This verifies the data and report back to Horde, whether they were correct. In this case Horde generates a PHP session, in which the authentication status is stored, and sends back a cookie to the browser with which this session is identified as long as the user is logged on.

But exceptions prove the rule. It is also the possibility that users using "transparent" to register authentication, without going through the registration form of Horde. This is for any form of SSO is the case. An SSO scenario could look like this: The user logs on to an external authentication provider. This sets a cookie in the browser, which we evaluate in Horde in order to read the data of the authenticated user in the database and use it in Horde. Once this is done successfully, the user is (transparent, without further user interaction) in Horde authenticated, Horde turn sends a session cookie to the browser, and it goes on as the first example.

In both cases, the credentials are provided by the browser, however, either as form data, cookies, HTTP headers, etc.

Another exception are interactions with horde that are NOT run through a browser. These include, for example, calls to the Horde API RPC mechanisms (SOAP, etc.), access to external clients (eg calendar clients) or synchronization clients ( SyncML , ActiveSync ). All these methods have in common is that they pass the user's browser without the need to credentials. Some may after all HTTP authentication yet, but some protocols use completely separate authentication methods. These include the synchronization clients. This is usually not a problem, it requires username and password then just the alternative protocol received over and over Horde driver's authentication to the backend authentication passed.

Problems arise when these two cases together, if we have a protocol that delivering a user name and password, the authentication back end but will be quite different, such as a browser cookie file. This cookie is obtained only yes, if you look at the browser to the external authentication provider logs. The synchronization client is not a browser can not display a HTML application form and does not even support cookies.

The only solution for this case, if the external authentication provider, nor an alternative interface to the application is available, eg via an RPC API. Could the Horde authentication driver from first to try the transparent authentication, and if that fails allow even a classic application by username and password.

Wie Authentifizierung in Horde funktioniert

Wenn Horde über den Browser benutzt wird, meldet sich der Benutzer in der Regel über ein Formular an. Die Benutzername-Passwort-Kombination wird vom Horde-Authentifizierungs-Treiber an das Authentifizierungs-Backend weitergegeben. Dieses überprüft die Daten und meldet an Horde zurück, ob sie korrekt waren. In diesem Fall erzeugt Horde eine PHP-Session, in der der Authentifizierungs-Status gespeichert wird, und schickt einen Cookie an den Browser zurück, mit dem diese Session identifiziert wird, so lange der Benutzer angemeldet ist.

Doch Ausnahmen bestätigen die Regel. So gibt es auch die Möglichkeit, die Benutzer per "transparenter" Authentifizierung anzumelden, ohne über das Anmeldeformular von Horde zu gehen. Dies ist bei jeder Form von SSO der Fall. Ein SSO-Szenario könnte so aussehen: Der Benutzer meldet sich bei einem externen Authentifizierungs-Provider an. Dieser setzt im Browser einen Cookie, den wir in Horde auswerten, um damit die Daten des authentifizierten Benutzers in der Datenbank zu auszulesen und in Horde zu verwenden. Sobald dies erfolgreich geschieht, gilt der Benutzer (transparent, also ohne weitere Benutzer-Interaktion) in Horde als authentifiziert, Horde schickt wiederum einen Session-Cookie an den Browser, und es geht weiter wie im ersten Beispiel.

In beiden Fällen werden die Anmeldedaten aber vom Browser bereitgestellt, entweder als Formulardaten, Cookie, HTTP-Header, o.ä.

Eine weitere Ausnahme sind Interaktionen mit Horde, die NICHT über einen Browser ablaufen. Dazu zählen z.B. Aufrufe der Horde-API über RPC-Mechanismen (SOAP etc.), Zugriffe mit externen Clients (z.B. Kalender-Clients) oder mit Synchronisations-Clients (SyncML, ActiveSync). Allen diesen Methoden ist gemeinsam, dass sie die Anmeldedaten des Benutzers ohne Browser übergeben können müssen. Einige können immerhin noch HTTP-Authentifizierung verwenden, manche Protokolle benutzen aber komplett eigene Authentifizierungs-Methoden. Dazu gehören die Synchronisations-Clients. Dies ist in der Regel kein Problem, es werden Benutzername und Passwort dann eben über das alternative Protokoll entgegengenommen und über Horde's Authentifizierungs-Treiber an das Authentifizierungs-Backend weitergegeben.

Problematisch wird es, wenn diese zwei Fälle zusammentreffen, wenn wir also ein Protokoll haben, dass Benutzername und Passwort anliefert, das Authentifizierungs-Backend aber eine ganz andere Information, z.B. einen Browser-Cookie benötigt. Diesen Cookie erhält man ja nur, wenn man sich mit dem Browser beim externen Authentifizierungs-Provider anmeldet. Der Synchronisations-Client ist aber kein Browser, kann kein HTML-Anmeldeformular anzeigen und muss noch nicht einmal Cookies unterstützen.

Die einzige Lösung für diesen Fall ist, wenn der externe Authentifizierungs-Provider noch eine alternative Schnittstelle zur Anmeldung zur Verfügung steht, z.B. über eine RPC-API. Dann könnte der Authentifizierungs-Treiber von Horde zunächst die transparent Authentifizierung probieren, und wenn diese fehlschlägt noch eine klassische Anmeldung per Benutzername und Passwort ermöglichen.