Sophie

Sophie

distrib > Mageia > 4 > x86_64 > by-pkgid > e5dacb39141c2088e2c30e21fa0b2b06 > files > 29

nagios-check_mk-doc-1.2.3i1-3.mga4.noarch.rpm

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.