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