[vz-users] VZ-Frontend Auth - Anmelden mit Zugangsberechtigungen - Hilfestellungen und Wiki-Artikel

[Frank Richter]

Hi Michael,

Am 19. März 2018 um 22:44 schrieb Michael Koch <princemichi at gmail.com>:

Ich erhoffe mir, das die Urheber der Auth-Funktionen alle Parameter in der
> Config einmalig odentlich beschreiben:
>

ich mach mal einen Versuch, bin aber wie gesagt kein Urheber, sondern nur
Alpha- oder Betatester.


a) Erläuterungen Firewall: Was ist ips, methods, action und wie wirken
> diese zusammen.
>

Die beiden 'ips'-Blöcke sorgen dafür, dass Requests von localhost und aus
dem lokalen Netzwerk durchgelassen werden.

'methods' filtert nach HTTP-Methoden. VZ benutzt GET/POST/PUT/DELETE (siehe
API-Referenz). Die Beispielkonfig [ 'methods' => 'GET', 'action' => 'allow'
] sorgt dafür, dass Lesezugriff von extern ohne Login möglich ist. Wer das
nicht will, ändert 'allow' auf 'auth' oder löscht den Block komplett, dann
gilt ebenfalls 'auth' wie für alle übrigen Requests (letzter Block).

Als 'action' sind 'allow', 'auth' und 'deny' zulässig. Das ist wohl
selbsterklärend.



> b) Was muss ich einstellen, wenn ich z.B. einem bestimmten Client zulassen
> möchte ... z.B. erläutert durch verständliche Anwendungsfälle.
>

Wenn sich der Client außerhalb des internen Netzes befindet, und die
verwendete Methode mit "auth" konfiguriert ist (z.B. POST für einen
Logger), muss er sich mittels Token im HTTP-Header authentifizieren. Ein
Browser besorgt sich dieses Token beim ersten Zugriff auf das Frontend
mittels User/Password und legt es zur weiteren Verwendung in den Cookies ab.
Weil der Logger das nicht kann, muss das Token auf dem Server generiert
werden und der Logger so konfiguriert werden, dass er es in den Header der
verschickten Requests einbaut.

Mit curl geht das z.B. so: curl https://domain.tld/
middleware.php/data/uuid.json --header "Authorization: Bearer <token>"

Zur manuellen Generierung von Tokens (z.B. auch mit langer Gültigkeit) gibt
es misc/tools/token-helper.php
Bitte einfach mal ausprobieren und mit den Tokens aus den Browser-Cookies
vergleichen. Für die Analyse von Tokens hilft ebenfalls die
token-helper.php mit der Option decode oder der Debugger auf https://jwt.io/

Neben dem verwendeten User und der Gültigkeit lassen sich bei der
Erstellung von Tokens auch constraints, also Beschränkungen auf
HTTP-Methoden und Kontexte berücksichtigen. Für einen Logger kann man also
ein Token erstellen, bei dem nur POST auf data erlaubt ist. Also kein
Lesezugriff, kein Löschzugriff und kein Zugriff auf Kanäle o.ä.. Das senkt
das Risiko für den Fall, dass ein Token in falsche Hände gerät.

Ich zitiere mal einen Schnipsel aus einer Mail von Andreas aus der
Entwicklungsphase:

php misc/tools/token-helper.php decode $(php misc/tools/token-helper.php
create andig --operation add --context data --valid 1.1.2019)
{"sub":"andig","iat":1516536798,"exp":1546297200,"vz:ctx":"d
ata","vz:ops":"POST"}

In diesem Fall darf das 1 Jahr gültige Token ausschließlich “POST” auf den
“/data” Kontext, also nur neue Daten anlegen aber nix löschen.



> c) Was kann ich mit $config['proxies'] einstellen? 1x auf Deutsch bitte ...
>

Daran hab ich nie was geändert. Regelt wohl die Handhabung von Proxies im
lokalen Netz (hab ich nicht).
Würde mal davon ausgehen, dass es sich um eine sinnvolle Grundeinstellung
handelt, die die üblichen IP-Bereiche für lokale Netze abdeckt.



> d) Was bewirkt $config['authorization'] ?? Auch hier benötigt man ein mal
> eine Erläuterung für das Wiki. Die Kommentare in der Config sind sehr
> "knapp".
>

Naja, 'secretkey' ist das früher schon angesprochene salt für die
Verschlüsselung. Weil es wenig Sinn macht, dass das öffentlich auf GitHub
steht, muss es für jede Installation individuell gesetzt werden. Vielleicht
sollten wir perspektivisch ein Script anbieten, dass einen bei der
initialen Konfiguration der Firewall an die Hand nimmt und dort auf Wunsch
ein paar zufällige Zeichen einträgt. Das secret kann ebenfalls mit dem
Debugger von jwt.io geprüft werden.

'valid' bestimmt die Gültigkeitsdauer der generierten Tokens in Sekunden.
Nach Ablauf dieser Zeit ist im Browser ein neues Login erforderlich. Mit
token-helper.php können wie erwänt Tokens mit abweichender Gültigkeit
generiert werden.



> e) Ausschließlich $config['users']['plain'] ist für mich selbsterklärend.
>

Immerhin :-)


f) $config['users']['constraints'] ist für mich auch noch ein Buch mit 7
> Siegeln...
>

Das war ein Wunsch von mir, nachdem Andreas Tokens mit eingeschränkten
Rechten eingeführt hatte. Für constraints gilt das oben gesagte (Methode
und Kontext sind konfigurierbar).
Damit kann man z.B. einen Gastnutzer bauen, der Daten zwar anschauen, aber
nicht ändern, nicht löschen und auch nicht loggen kann.


> Gerne auch mal einige Ausführungen zum konzeptionellen Aufbau und
> Funktionsweise insbesondere der Firewall Settings.
>
Da muss ich passen. Muss man aber IMHO auch nicht kennen, um es zu
verwenden. Vielleicht mal in der Doku von JWT umsehen?

Als Warnung sollte man vielleicht nochmal betonen, dass alles, was
Authentifizierung betrifft, nur sinnvoll in einem Umfeld mit HTTPS genutzt
werden kann, sonst ist es mit Sicherheit nicht weit her...

Viele Grüße
Frank


*From:* Frank Richter [mailto:frank.richter83 at gmail.com
> <frank.richter83 at gmail.com>]
> *Sent:* Monday, Mar 19, 2018 13:50 GMT+0100
> *To:* volkszaehler.org - users <volkszaehler-users at demo.volkszaehler.org>
> <volkszaehler-users at demo.volkszaehler.org>
> *Subject:* [vz-users] VZ-Frontend Auth - Anmelden mit
> Zugangsberechtigungen - Hilfestellungen und Wiki-Artikel
>
> Hi Michael,
>
> das ist eher was für die vz-dev Mailingliste.
>
> Was ist ist denn unklar bzgl. Firewall-Config?
>
> Ansonsten würde ich Daniel zustimmen, ein Artikel gehört thematisch zur
> Middleware.
>
> Grüße
> Frank
>
> Am 18. März 2018 um 16:37 schrieb Michael Koch <princemichi at gmail.com>:
>
>> Hallo an Alle!
>> Andreas hat vor geraumer Zeit einen Pull Request
>> <https://github.com/volkszaehler/volkszaehler.org/pull/659> geschrieben,
>> mit dem es möglich ist den Zugang zum Frontend nur berechtigten Usern zur
>> Verfügung zu stellen.
>> Jetzt haben wir uns darauf geeinigt diesen in den Master zuintegrieren,
>> damit alle Installationen von diesem großartigen Feature profitieren können.
>> Hierbei gibt es einige Punkte zu Berücksichtigen:
>> - Die PHP Reqirements werden auf PHP 7.0 angehoben, ältere
>> Webserverkonfigurationen müssen auf ältere VZ-Versionen zurückgreifen
>> - Aufgrund derzeit fehlender Backend-Konfiguartion muss der neue Auth in
>> den Config-Files manuall eingerichtet werden.
>> Ziel dieses Threads ist es einen geeigneten Wiki-Artikel auf die Beine zu
>> stellen um allen eine einfache Konfiguration zu ermöglichen.
>> Ich pers. gebe zu, das ich noch einige Probleme mit der
>> Firewall-Konfiguartion habe.
>> Ich bitte als einmalig darum, hier die Einstellmöglichkeiten von euch
>> erklärt zu bekommen, damit wir einen passenden Wikiartikel erstellen
>> können.
>>
>> Nächste Frage: Wie soll dieser Artikel im Wiki heißen? Mein Vorschlag:
>> https://wiki.volkszaehler.org/software/frontends/frontend/auth
>>
>> Beste Grüße,
>>
>> Michael
>>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://demo.volkszaehler.org/pipermail/volkszaehler-users/attachments/20180323/5bcf43be/attachment-0001.html>