[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