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