[cvs] [Wiki] created: Doc/Dev/Authentication

Jan Schneider jan at horde.org
Thu Jun 10 09:16:36 UTC 2010


jan  Thu, 10 Jun 2010 05:16:36 -0400

Created page: http://wiki.horde.org/Doc/Dev/Authentication

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



More information about the cvs mailing list