Vorschlag zur Benutzerauthorisierung

[TCr82]

Hallo Leute,

da ich dazu aufgefordert wurde meine Idee hier mal kund zu tun, hab ich mal auf die schnelle mit Paint ne kleine Skizze gebastelt die meine Erklärung unterstützen soll.

vorschlag Auth.png

Ich denke die Grafik erklärt wie das System funktionieren soll.
smartVISU soll dazu die Zugriffe kontrollieren. Bedeutet man müsste eine Benutzer/Gruppen-verwaltung bauen. Als Admin sollte man wissen, dass man besser alle Rechte an Gruppen aufhängt. Somit würde man dann z.B. im HTML Code der Visu den Zugriff auf das Objekt über Nennung der Gruppe und deren Rechte definieren.

Dabei trackt die Visu immer über die SessionID welche Rechte der Benutzer hat (anonym oder angemeldet). Dementsprechend werden die Elemente entweder ausgeblendet oder gar nicht ausgeliefert. Bei jeder Zugriff auf den Websocket von smarthome.py wird die Session-ID von der VISU mitübermittelt (möglich wären noch andere Identifizierungsmerkmale wie IP / UserAgent usw). Smarthome frägt nun bei der Visu nach, ob diese Session-ID aich authorisiert ist. Am besten wäre das irgendwie zu Cachen (für 2-3 Sekunden, k.a....) um die Performance zu verbessern. Wenn man es cacht, sollte die Visu auch in der lage sein, smarthome.py über die änderung der SessionID mitzuteilen, also wenn z.B. der Benutzer sich eingeloggt hat (oder der Benutzer bekommt immer eine neue Sitzungs-ID, nach dem Login).

Naja, das ist mein Gedanke... was haltet ihr von der Idee? Sollte doch realisierbar sein

Gruß,
Thomas

[psilo]

Nur für mein Verständnis: smartVISU IST doch das Front-End?! Und wenn nicht, welchen Sinn macht die SV dann noch? Oder ist Frontend für Dich nur der JS "Treiber"? Dann ist der Bezeichner imho etwas unschön gewählt. Eine Drecksbeziehung trägt zudem der Stabilität nicht bei, denke ich, kennt man ja aus dem echten Leben

[TCr82]

Ja, Frontend war wohl nicht eindeutig gewählt - ich meinte natürlich den Browser. Aber diese "Dreiecksbeziehung" hat nichts mit dem waren leben zu tun (in Punkto Partnerbeziehung) - deswegen hängt der Vergleich etwas. Das solche Dinge gut funktionieren können, zeigt die Informatik in vielen Projekten. Es ist einfach eine Sache der technischen Umsetzung.

[TCr82]

Es ist auch gar nicht anders zu realisieren - ausser man Integriert die VISU in smarthome oder umgedeht ;-)

[smai]

Es ist auch gar nicht anders zu realisieren - ausser man Integriert die VISU in smarthome oder umgedeht ;-)

Da möchte ich widersprechen. Auch wenn dein Vorschlag nicht falsch ist, gibt es noch einige andere Ansätze.

1. SH.py könnte als Authentifizierungsprovider agieren, sprich Benutzer, Gruppen und Passwörter werden dort verwaltet.
Das Loginformular wird natürlich trotzdem in der SV angezeigt, diese reicht aber die Daten weiter an SH.py und erhält als Antwort ein Token (ähnlich einer Session ID), welches dann beim Websocket Request angehängt wird.
Vorteile dieser Lösung:
- Man könnte bereits in SH.py für jedes Item definieren, welche User es lesen oder schreiben dürfen.
- SH.py muss nicht bei der SV wegen der Autorisierung zurückfragen.

2. HTTP Basic Auth
In der SV kann dies bereits heute problemlos eingesetzt werden, da es sich dabei um ein Standardfeature jedes Webservers handelt.
Anscheinend funktioniert dies auch mit Websockets. Man müsste dies also nur in SH.py aktivieren (oder noch implementieren?).
Vorteil:
- Wohl am einfachsten zu implementieren.

3. WebSocket Proxy mit HTTP Basic Auth
Anstatt die WebSocket-Verbindung direkt mit SH.py herzustellen, könnte in der SV bzw. deren Webserver ein Proxy eingerichtet werden (im FHEM Forum habe ich mal sowas gesehen). Dieser wäre automatisch mit Basic Auth mitgesichert.
Weitere Vorteile des Proxy's:
- Kann für alle Backends mit WebSocket verwendet werden.
- Keine Anpassung in SH.py notwendig, damit auch keine weiteren Abhängigkeiten voneinander.
- Die WebSocket-Verbindung könnte einfach per SSL mitgesichert werden.
- SH.py muss nicht mehr vom Client her erreichbar sein. Dies erhöht die Sicherheit und vermindert Probleme mit der DNS-Auflösung.
- Evtl. muss nicht mal mehr ein separater Port freigegeben werden (ist zu prüfen).

Ich persönlich würde die 3. Variante bevorzugen.

Gruss
Stefan

[TCr82]

Also Methode 2 und 3 haben den Nachteil, dass man den Zugriff generell nur erlauben kann oder eben nicht. Also sehr unflexiebel, da es nicht sowas wie ein Admin geben kann der alles darf und ein Benutzer der nur Basics machen darf....

Aber zu 3. ja kein neuer Port nötig... aber du hast ja selbst schon bei der Abhängigkeit zu mod_rewite gemurrt, dann kommst du mit dem reverse proxy, was nochmal aufwändiger ist.

Zu Methode 1:
So wie du es beschreibst, ist es aber trotzdem eine Dreiecksbeziehung (also zum Stichwort es lässt sich nicht ohne realisieren).
Auch stelle ich mir vor, dass es unflexibel wird in der Visu das zu handhaben. Außerdem sind Änderungen bzgl. user/pw/gruppen immer in sh.py zu leisten.

Für mich käme da noch eine neue Methode auf: Alles wie zuvor in meinem Vorschlag, nur dass die Items in sh.py die Rechte enthalten.

So wäre die interne Kommunikation (Step 3 in meinem Beispiel) z.B. so:
sh.py frägt bei der Visu, welche Gruppe die SitzungsID X hat und schaut danach intern nach, ob der Zugriff darauf möglich ist.

Ich denke halt auch darüber nach, wie es gelöst wird, dass die Visu sich je nach angemeldetem Benutzer ändert. Also in der Hinsicht das sich Menüpunkte/Widgets ausblenden & deaktivieren bzw. nicht da sind (also nicht in der html Ausgabe sind).

Und Methode 1 oder meine kann man trotzdem - optional - mit dem Reverse Proxy zusammen benutzen um nur einen Port zu haben.

[psilo]

Mal eine andere Frage: für welche Usecases seht ihr überhaupt eine komplexe Userverwaltung? Für mich reicht der VPN Access, die Familie darf intern defakto sowieso alles... Das Backend von SHNG sichere ich via Basic Auth ab.. Auch mit Userverwaltung würde ich mein Heimnetzwerk nie offen lassen, daher sehe ich für mich nicht wirklich den Anwendungsfall?!

[bmx]

Also es gibt mehrere Stellen, an denen Items innerhalb SHNG nur mit Erlaubnis geändert werden dürfen. Klassisch haben wir drei Plugins: Den Visu_websocket, CLI und Backend. Ich möchte durchaus meiner Familie Zugriff einräumen auf Licht, Zeitschaltuhren etc. Allerdings gibt es Sachen wo ich nicht möchte, das da jemand rumfuhrwerkt nur weil ich auf der VISU dort einen Button habe. Und eine Webseite kann ich als gewitzter Jugendlicher auch kopieren, modifizieren und Dinge wie Fernsehersperre umgehen.
Insofern würde ich mich über eine zentrale Implementation von Benutzern/Gruppen in SmartHomeNG schon freuen.
Das grundsätzlich nur innerhalb eines Gebäudes auf die VISU jemand Zugriff hat und von außerhalb nur via VPN sehe ich auch so.

[psilo]

bmx ich wette meine Kids haben wenn sie mal älter sind schneller meinen Server geknackt als ich "Huch" sagen kann.. so wie die nächste Generation in Sachen IT der letzten vornewegpresscht.. Und das sage ich als beruflicher ITler...

[smai]

Mit Basic Auth kann man doch ebenfalls Gruppen bilden und individuelle Berechtigungen vergeben. Auch könnte man diese problemlos in php implementieren, ohne Abhängigkei vom Webserver.

Von der Komplexität der Berechtigungssteuerung in der Visu bin ich irgendwo zwischen psilo und TCr82: Ich kann mir sicher zwei Stufen vorstellen, normaler User zum Bedienen und Admin zum Konfigurieren. Allenfalls noch eine Dritte mit eingeschränkter Bedienung.
Aber ob man wirklich für jedes Widget einzeln festlegen will, wer es bedienen darf und dazu auch noch individuelle Gruppen bilden, bin ich mir nicht so sicher.

[TCr82]

psilo : also das deine Kids das bei dir Schaffen ist eine Sache.. ich als Admin und Sicherheitsberater kann das schon Ausschließen. Es ist also jedem selbst überlassen. Und wie immer spielen da halt mehrere Faktoren eine Rolle.

EDIT: Aber mal im Umkehrschluss... wenn sie das Schaffen, dann haben sie auch das Zeug dazu dass ganze mit zu managen ;-)

smai : also ich weiss, dass man in PHP auch den Basic Auth implementieren kann, da ich es selbst schon in einem Projekt durchgeführt habe. Aber genau deswegen weiss ich dass es einfach mehrere Einschränkungen gibt, die bei einer guten Implementierung über einen Cookie/Session Auth nicht gibt. Und wenn man schon damit anfängt das in PHP zu Coden ist es einfach besser das gleich richtig zu machen, als dass man um 5 Ecken herum etwas baut.

Ohne Basic Auth stehen einem da einfach mehr Möglichkeiten offen, wie Kennwort zurücksetzten, CAPTCHA abfragen, 2 Faktor Auth, uvm,

Da braucht es auch nicht zwingend VPN, wenn es Sicher umgesetzt wird.

Ich vermute du sträubst dich vor der Integration einer Benutzerverwaltung, evtl. wegen des hohen Aufwands? Ich bin gerne Bereit den Code beizusteuern. Ist halt bei mir immer etwas Langwierig, da ich Familie habe und die Zeit immer begrenzt ist - und somit nicht an einem Stück an der Sache arbeiten kann. Design müsste allerdings von den Designern optimiert werden, da dass überhaupt nicht mein Ding ist.

[psilo]

TCr82 Auch den Admin und Sicherheitsberater könnte die nächste Generation überholen, wetten?

Einige der Studenten die ich in Informatik an der Uni vor 4 Jahren betreut habe, hatten meinem Gefühl nach das Programmieren schon im Windelalter gelernt.. Wenn man wie ich anno 1996 erst kurz vor dem Abi Internet hatte und damals die Bedienung von Word, Programmieren in PASCAL und ein bischen neuartiges "HTML" auf dem Mosaic Browser zur Kernkomptenz gehört hat, durchaus irritierend.

PS: nein ich sträube mich nicht wegen des hohen Aufwands, ich will nur Argumente, warum man das unbedingt braucht. Zudem muss das dann vollintegriert sein, da SHNG ja auch auf diversen Ports Dinge wie das Network oder Backend Plugin bereitstellt. Meist spielt auch die zugrundeliegende Landschaft eine Rolle. Ich habe alles auf einer Synology, da sind noch mehr Dienste offen.

Eine Benutzerverwaltung suggeriert dem Einsteiger dann es ist sicher, wärend ein Haufen anderes Zeug offen im Netz steht.

Und dann kommt dazu, dass hier nicht jeder SV User auch SmartHomeNG nutzt.. Dann muss der Rest theoretisch auch nachgezogen werden..

[Tom Bombadil]

Eine Benutzerverwaltung suggeriert dem Einsteiger dann es ist sicher, wärend ein Haufen anderes Zeug offen im Netz steht.

Und dann kommt dazu, dass hier nicht jeder SV User auch SmartHomeNG nutzt.. Dann muss der Rest theoretisch auch nachgezogen werden..

Mal abgesehen davon, dass ich den Sinn der ganzen Sache nicht ganz sehe (wohl eher Ansichtssache) - aus genau diesen Gründen bin ich der persönlichen Auffassung, dass eine "Benutzerauthentifizierung" momentan für das Projekt eher kontraproduktiv ist. Ich hab noch 12 Jahre mehr in der IT/Softwareentwicklung auf dem Buckel, psilo. Und in dieser Zeit etliche Projekte gesehen, in denen die Programmierer sich am Anfang erstmal auf die Nutzerverwaltung gestürzt haben - ist ja ein bequemes, weil (oberflächlich betrachtet) einfaches Thema.

Nach einigen Monaten kommt dann immer die Einsicht, dass eine gründlich gemachte Benutzer- und Gruppenverwaltung ein Fass ohne Boden ist. Nach einem halben bis dreiviertel Jahr hängt man dann mitten in irgendwelchen ungelösten Rechteproblemen in den Seilen, es ist aber noch nicht eine tatsächliche Zeile Code für den eigentlichen Zweck des zu schaffenden Anwenderprogramms geschrieben worden. Leider zu oft selbst erlebt.

Da ich weiß, dass Stefan momentan an vielen elementaren Dingen in der Visu schraubt, z.B. vernünftige und vereinheitlichte Kalender- und Wetterdienst-Anbindung, Vereinheitlichung und Ausbau der Widgets, angepasstes Caching, etc etc, glaube ich persönlich nicht, dass dies die richtige Zeit ist, diese Büchse der Pandora zu öffnen. Vielleicht sollte man erstmal die 2.9, die gefühlt eher die Dimension einer 3.0 oder 4.0 hat, abwarten ... just my 2 cents ...

/tom

[smai]

Ohne Basic Auth stehen einem da einfach mehr Möglichkeiten offen, wie Kennwort zurücksetzten, CAPTCHA abfragen, 2 Faktor Auth, uvm,

Das alles möchte ich eigentlich gar nicht in der SV haben.

Ich vermute du sträubst dich vor der Integration einer Benutzerverwaltung, evtl. wegen des hohen Aufwands?

Eher wegen der hohen Komplexität in der Bedienung und Wartung. Wenn man sowas einbindet, muss es auch wirklich sicher sein. Sonst ist es wie psilo schreibt, eine suggerierte Sicherheit, die gefährlich ist (so einig mit psilo war ich schon lange nicht mehr)
Und so ein System muss vom Betreiber gewartet werden. Klar könnte man sagen, es sei nicht mein Problem, was die Leute mit meinem Open Source Code machen. Aber ich finde, ein Programmierer hat schon eine ethische Verantwortung.

Mir widerstrebt auch sehr die Session in dieser Anwendung. Diese bringt es mit sich, dass auch ein Session Timeout auftritt, das behandelt werden muss und ein erneutes Login verlangt.
Ich gehe davon aus, dass viele die SV auf einem dedizierten Gerät nutzen (z.B. Tablet an der Wand). Da wäre ein Session Timeout nicht sinnvoll.

Die SV ist ja auch keine klassische Webapplikation, da sie eigentlich nur statische Inhalte zur Verfügung stellt. Die dynamischen Daten werden dann asynchron clientseitig aus anderen Systemen geladen.

Unabhängig von Art und Ort der Authentifizierung gehört die Berechtigungen auf einzelne Items für mich zwingend ins Backend, das macht in der Visu keinen Sinn.
In der Visu stellt sich nun die Frage was genau je User oder Gruppe gesteuert werden soll: Einzelne Widgets, ganze Seiten oder Bereiche innerhalb von Seiten (z.B. per Twig Tag markiert)?
Oder wäre es sogar sinnvoll, Widgets automatisch auszublenden, sobald keine Berechtigung auf die darin verwendeten Items besteht?

Tom hat natürlich recht, das Thema ist nichts für 2.9 (und wahrscheinlich auch 2.10). Aber als Grundatzdiskussion ist es durchaus berechtigt.

[Tom Bombadil]

[off-Topic, couldn't resist] 2.10 ist doof, da muss ich ja den von Dir schon abgenickten String-Vergleich der SV-Version nochmal anpassen:

{% if config_version < "2.9" %}
    {% import "widget_uzsu.html" as uzsu %}
    {{ uzsu.uzsu_icon(id, item, headline, designType, pic_on, pic_off, valueType, valueParameterList, color) }}
{% else %}
    /** -designType, -color, +color_on, +color_off **/
    {{ device.uzsuicon(id, item, headline, pic_on, pic_off, valueType, valueParameterList, color_on, color_off) }}
{% endif %}

Mach mal lieber 3

/Tom

Edit: Wenn ich die letzten Neuerungen richtig verstanden habe, braucht's die ID im unteren Teil nicht mehr - Mist, muss also sowieso anpassen ...