Module: check_mk
Branch: master
Commit: ddcba51dc0ca374ef23cc489a0b543c680675c01
URL: http://git.mathias-kettner.de/git/?p=check_mk.git;a=commit;h=ddcba51dc0ca37…
Author: Mathias Kettner <mk(a)mathias-kettner.de>
Date: Wed Nov 23 12:56:48 2011 +0100
Whitepaper about Cookie authentication
---
doc/LIESMICH.cookieauth | 75 +++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 75 insertions(+), 0 deletions(-)
diff --git a/doc/LIESMICH.cookieauth b/doc/LIESMICH.cookieauth
new file mode 100644
index 0000000..9bce743
--- /dev/null
+++ b/doc/LIESMICH.cookieauth
@@ -0,0 +1,75 @@
+Authentifizierung mit Cookies
+-----------------------------
+
+Zielsetzung:
+
+* Login nicht per HTTP Auth, sondern über eine hübsche Loginmaske.
+ Warum? Nur weil es hübsch ist. Andere Vorteile sehe ich aktuell
+ nicht. Ausloggen geht ja mittlerweile auch über HTTPBasicAuth.
+
+* Login soll in den Addons Multisite, NagVis und PNP4Nagios funktionieren.
+
+
+Umsetzung:
+
+* Die Passworte bleiben nach wie vor in der Datei htpasswd (verschlüsselt).
+ Damit ist man auf jeden Fall kompatibel.
+
+* Wenn man auf index.py kommt (das Frameset) und hat noch kein Login-Cookie,
+ dann kommt anstelle des Framesets eine Einloggemaske. Dort gibt man Name
+ und Passwort ein und kann evtl. noch - wenn wir nett sind - seine Sprache
+ einstellen.
+
+* Das eingetippte Passwort wird gegen die htpasswd-Datei geprüft. Dabei wird
+ zumindest MD5 (verwendet WATO) und crypt (default von htpasswd) unterstützt.
+
+* Wenn das erfolgreich ist, wird ein Login-Cookie generiert. Dieses enthält
+ folgende Daten im Klartext:
+ - Loginname
+ - Verfallszeit als Timestamp. Wenn das 0 ist heißt es "unendlich"
+ Die Verfallszeit wird - in multisite.mk einstellbar - auf die Zukunft gesetzt,
+ z.B. auf 60 Minuten. Das ganze ist pro Benutzeraccount einstellbar.
+ Nach Ablauf der Zeit verfällt das Cookie.
+
+ Diese beiden Angaben werden jetzt noch kombiniert mit dem verschlüsselten
+ Passwort und einem Geheimnis, dass in der Datei etc/auth.secret gespeichert
+ wird. Alle vier Werte werden durch Pipesymbole zusammengehängt, z.B.
+ "harri|123909495|$1$090775$8M/9Eq3MlnP4yhafnc1ef/|L8jJLlk3ekFL"
+ Dieser String wird jetzt mit MD5 gehäscht und daraus ein Cookie gebildet,
+ z.B. "harri|123909495|89a3292c8a1496e864a4ba3d4080cad9". Dies ist dann
+ der Inhalt des Cookies.
+
+* Das etc/auth.secret wird automatisch ausgewürfelt, wenn es noch nicht
+ da ist.
+
+* Die WATO-Replikation muss auch das Secret mit replizieren, damit eine
+ Anmeldung auch Remote immer gültig ist.
+
+* Der Pfad zu etc/auth.secret wird aus dem Pfad zur htpasswd-Datei
+ gebildet. Diese ist Check_MK bekannt und steht in den Defaults in
+ der Variable "htpasswd_file". Davon nimmt man den dirname.
+
+* Zum Überprüfen holt man Loginname und Verfallszeit aus dem Cookie. Ist
+ die Zeit abgelaufen, wird das Cookie verworfen. Dann holt man sich
+ das auth.secret und das verschlüsselte Passwort des Users und bildet
+ erneut den Rohstring und häscht diesen. Wenn die MD5-Summe mit der im
+ Cookie übereinstimmt darf man weiter. Wenn das Cookie eine Verfallszeit
+ hat und *keine* Ajax-ID gesetzt ist, wird das Cookie automatisch erneuert.
+
+* Wenn man irgendeine Seite außer index.py aufruft und *kein korrektes* Cookie hat,
+ dann wird man irgendwie weitergeleitet auf die Loginmaske. In dieser wird die
+ eigentlich URL hidden mitgespeichert, so dass man nach dem Einloggen da weitermachen
+ kann, wo man eigentlich hinwollte.
+
+* PNP und NagVis müssen ebenfalls in der Lage sein, ein Cookie zu überprüfen
+ und zu erneuern. Dazu muss man den Code für das Überprüfen des Cookies auch
+ in PHP schreiben.
+
+* Die Einstellung, ob man htpasswd oder Cookies macht, ist einfach: Wenn beim
+ index.py bereits ein user bekannt ist (von Apache), nimmt man den. Ansonsten
+ nimmt man die Cookies.
+
+* omd config bekommt eine Variable, die das steuert. Diese schaltet dann
+ die Apache-Konfiguration für Check_MK, PNP und NagVis um. Wenn andere
+ Lust haben (Thruk, etc.) können die sich auch dranhängen.
+