Modularisierung der Authorisierung/Authentifizierung

rudolfkoenig · 29 Dezember 2015, 20:39:07

Angeregt von diese und jene Diskussion habe ich die Authorisierung (frueher allowedCommands) und Authentifizierung (basicAuth/password) Modularisiert, wie das hier schon angedeutet wurde.

Falls ein Modul eine AuthorizeFn anbietet, und eine Instanz dieses Moduls existiert, dann wird diese Funktion
- vor dem Ausfuehren jedes Befehls, was direkt von einem Frontend stammt, mit dem Hash des Frontends und dem Befehl aufgerufen. Sie kann 0 (interessiert mich nicht), 1 (erlaubt) oder 2 (verboten) zurueckliefern. Funktionalitaet wie der bisherige allowedCommands.
- danach (wieder nur "Frontend" Befehle), falls ein Befehl devspec2array verwendet, wird diese Funktion (mit anderen Parametern) fuer jedes zutreffende Geraet einzeln aufgerufen. Funktionalitaet wie das vorgeschlagene allowedDevices.

Falls ein Modul eine AuthenticateFn anbietet, und eine Instanz dieses Moduls existiert, dann wird diese Funktion von FHEMWEB und vom telnet aufgerufen. Rueckgabewerte aehnlich: 0: keine Authentifizierung notwendig, 1: Authentifizierung ok, 2: Authentifizierung fehlgeschlagen.

Als Beispiel bzw. zur Bewahrung der bisherigen Funktionalitaet habe ich 96_allowed.pm gebaut, der die bisherigen Attribute allowedCommands, allowedDevices, basicAuth, passwort in sich vereint.

Falls ein Benutzer einen dieser Attribute gesetzt hat, dann wird fuer die betroffenen Instanzen jeweils eine neue allowed_<alteName> Instanz angelegt (validFor wird entsprechend gesetzt) und mit den Attributen versehen.

Ich vermute durch den Umbau ist allowedCommands in yowsup.pm erstmal wirkungslos geworden, bitte anpassen. Bei FLOORPLAN bin ich nicht ganz sicher, ich vermute es funktioniert noch. Ich bitte um Feedback.

justme1968 · 29 Dezember 2015, 21:18:01

32_yowsup.pm habe ich gerade nachgezogen.

in dem zusammenhang ist mir aufgefallen das es ausser featurelevel (das hier auch nicht verwendet wird) keine möglichkeit gibt festzustellen ob das gerade eingesetzte fhem eine bestimmte funktionalität unterstützt. d.h. es ist nicht möglich das ein modul zumindest für die Übergangszeit das alte und das neue api unterstützt. ich vermute für yowsup ist das erst mal kein problem da ich der einzige bin der ein altes fhem mit einem neuen modul einsetzt. in anderem zusammenhang könnte das aber mal probleme machen.

kann es sein das die mehr oder weniger zufällige reihenfolge in der die AuthorizeFn und AuthenticateFn aufgerufen werden es unmöglich machen mit einer definierten allow/deny reihenfolge zu arbeiten wen ein modul das implementieren möchte?

die in meinem patch vorgeschlagenen änderungen an list, jsonlist2 und xmllist um die 'verbotenen' devices auch dort unsichtbar zu machen sind ja jetzt erst mal nicht mit drin. hat du eine idee wie man das halbwegs generell umsetzen kann?

justme1968 · 29 Dezember 2015, 21:56:39

das problem mit der aufruf reihenfolge kann man (etwas) entschärfen wenn man in Authorized die liste aller AuthorizeFn auch im allow fall bis zu ende durchgeht. d.h. nur im verboten fall vorzeitig abbricht.

beispiel:

für die fehmweb instanz ist ein zugehöriges allowed definiert und ein modul bringt selber noch mal eigenes allowed mit das stärkere einschränkungen hat. es hängt jetzt von der reihenfolge ab ob das zum modul gehörende allowed überhaupt zum zuge kommt.

viegener · 30 Dezember 2015, 01:13:00

Zitat von: rudolfkoenig am 29 Dezember 2015, 20:39:07
Als Beispiel bzw. zur Bewahrung der bisherigen Funktionalitaet habe ich 96_allowed.pm gebaut, der die bisherigen Attribute allowedCommands, allowedDevices, basicAuth, passwort in sich vereint.

Falls ein Benutzer einen dieser Attribute gesetzt hat, dann wird fuer die betroffenen Instanzen jeweils eine neue allowed_<alteName> Instanz angelegt (validFor wird entsprechend gesetzt) und mit den Attributen versehen.

Klingt ja spannend. Ich würde ja vorschlagen meinen ursprünglichen FHEMWeb-Patch so umzubauen, dass er in 96_allowed passt. So lässt er sich wenig invasiv umsetzen (im wesentlichen allowed_Authenticate und vermutlich noch allowed_Attr). Ich frage lieber vorher, damit ich den patch nicht umsonst erstelle...

Benni · 30 Dezember 2015, 10:10:54

Hallo Rudi,

wollte mir eben die Doku zu allowed in der Commandref anschauen.
Die habe ich schließlich "gut versteckt" hinter der Doku zum 2. at gefunden

rudolfkoenig · 30 Dezember 2015, 10:28:55

Zitatzufällige reihenfolge in der die AuthorizeFn und AuthenticateFn aufgerufen werden

Die Funktionen werden in der Reihenfolge der Instanznamen aufgerufen. Ich habe kein Problem ein zusaetzliches Attribut einzufuehren, meine z.Zt., dass es nicht notwendig ist.

Zitatdie liste aller AuthorizeFn auch im allow fall bis zu ende durchgeht

Wenn man das Implementiert, dann ist 1 als Rueckgabewert von AuthorizeFn sinnlos. Oder andersrum: dein Szenario kann man dadurch implementieren, dass man in AuthorizeFn nur 0 oder 2 zurueckliefert. Das habe ich jetzt in allowed umgesetzt.

Ich habe Authenticate angepasst, so dass bei Ablehnung so lange weitergefragt wird, bis einer der Module OK gibt. Hier funktioniert mit das Spiel 0 vs. 1 nicht, weil "keine Authentifizierung" ja ungleich "Authentifizierung nicht geklappt" ist.

Zitatlist, jsonlist2 und xmllist um die 'verbotenen' devices auch dort unsichtbar zu machen

Habs nachgezogen, danke fuer die Erinnerung. FHEMWEB bleibt unberuehrt davon, da muss man weiterhin mit hiddenroom herumspeilen.

ZitatIch würde ja vorschlagen meinen ursprünglichen FHEMWeb-Patch so umzubauen, dass er in 96_allowed passt.

Gerne, aber ich habe auch nichts dagegen, wenn das Feature in einem eigenstaendigen Modul implementiert wird.

ZitatDie habe ich schließlich "gut versteckt" hinter der Doku zum 2. at gefunden

Danke, habs korrigiert.

justme1968 · 30 Dezember 2015, 10:41:25

mit mehr oder weniger zufällig meinte ich von den jeweiligen device namen abhängig

das macht schon bei notify manchmal probleme. ich glaube das ist bei so etwas wichtigen wie security falsch.

wenn der benutzer keine möglichkeit hat die reihenfolge zu beeinflussen sollte das verhalten umgekehrt sein. das erste ablehnen gilt und bei ok wird so lange weiter gemacht bis die liste durch ist.

das ist nicht sinnlos. wenn es nur ok gibt und die liste zu ende ist dann ist ok das endergebnis.

sonst kann man z.b. keine module über fhemweb oder telnet verwenden die eine striktere policy haben. siehe beispiel oben. das ok von fhemweb überschreibt alles.

rudolfkoenig · 30 Dezember 2015, 11:02:39

Zitatdas ist nicht sinnlos. wenn es nur ok gibt und die liste zu ende ist dann ist ok das endergebnis.

Aber wenn kein ok von einem Modul gibt (nur ein "geht mich nichts an"), dann ist das Endergebnis doch auch ok. Insofern waere mit deiner Methode ok gleichwertig mit "geht mich nichts an".

justme1968 · 30 Dezember 2015, 11:10:13

bei ok und bei geht mich nichts an bis zum ende weiter machen. bei nein sofort nein zurück geben.

wie oben im beispiel beschrieben:

sobald ein modul eine eigene (spezifischere) AuthorizeFn mit bringt wird diese nicht mehr ausgewertet sobald die allgemeine für fhemweb davor aufgerufen wird. was sie aus alphabets gründen sogar fast immer wird. WEB kommt halt ziemlich weit hinten.

es sollte aber so sein das modul spezifische auf jeden fall aufgerufen wird.

rudolfkoenig · 30 Dezember 2015, 11:18:31

Wird doch: alle Auth-Module muessen 0/"geht mich nichts an" zurueckliefern, wenn sie zulassen wollen, dass andere Auth-Module ein Veto-Recht haben.

Sonst ist "ok" vom "geht mich nichts an" nicht zu unterscheiden. Oder anders: mit deinem Vorschlag muss auch das API geaendert werden, und AuthorizeFn darf nur "ok" oder "nicht ok" zurueckliefern. Wuerde nur die Funktionalitaet gegenueber jetzt einschraenken. Vielleicht ist es aber doch sinnvoll, damit ich nicht immer solche langen Argumentationsorgien abhalten muss

justme1968 · 30 Dezember 2015, 11:23:36

lach. sag doch einfach ich habe recht

aber im ernst:

im web gibt es ein allowedCommands das ein set erlaubt. im modul gibt es ein spezifischeres allowed das nur set xy erlaubt.

das funktioniert nur wenn bei ok weiter gemacht wird.

ps: vielleicht ist es ganz unabhängig von dieser diskussion sinnvoll log meldungen einzubauen welches modul was zurück gegeben hat und in welcher reihenfolge sie aufgerufen wurden. sonst wird das debuggen auch für den anwender unter umständen schwierig.

viegener · 30 Dezember 2015, 12:35:49

Zitat von: justme1968 am 30 Dezember 2015, 11:23:36
ps: vielleicht ist es ganz unabhängig von dieser diskussion sinnvoll log meldungen einzubauen welches modul was zurück gegeben hat und in welcher reihenfolge sie aufgerufen wurden. sonst wird das debuggen auch für den anwender unter umständen schwierig.

Absolut wichtig, ich befürchte sonst kann ein anwender uns nicht mal sinnvolle logs produzieren, mit denen die entwickler das problem nachvollziehen können. das sollte aber beim aufruf erfolgen, damit man das zentral ein/auschalten kann und auch die einträge standardisiert sind.

viegener · 30 Dezember 2015, 14:51:55

Zitat von: rudolfkoenig am 30 Dezember 2015, 10:28:55
Gerne, aber ich habe auch nichts dagegen, wenn das Feature in einem eigenstaendigen Modul implementiert wird.

Ich habe leider das Problem, dass die Cookie-Lösung sich so nicht realisieren lässt, da ja ein Header (set-cookie) NACH erfolgreicher Anmeldung gesetzt werden müsste. Aber .httpauthheader nur mitgeschickt wird wenn die Anmeldung notwendig ist und fehlt.

Der Cookie wird ja gesetzt wenn die Anmeldung erfolgreich war und der normale Inhalt (für den ersten Request) zurückgeht.
Könnte man den .httpauthheader auch in anderen Fällen mitsenden (sozusagen ein .httpauthtokenheader)
Alternative: Ein zusätzlicher .httpServerHeader, der auch von anderen Erweiterungen (nicht nur Auth gesetzt werden könnte)?

Loredo · 30 Dezember 2015, 14:55:06

Ich fände es besser eine echte formularbasierte Anmeldung zu haben.
BasicAuth lässt sich nicht mit Passwortmanagern wie 1Passwort verwenden.

Loredo · 30 Dezember 2015, 15:50:00

Als Alternative Anmeldemöglichkeit für zB um die GUI als MobileWeb.app inkl authentifizierung abspeichern zu können, sollte man sich auch per Auth-Token in der URI anmelden können (BasicAuth geht hier auch, ist aber umständlicher und nicht so schick vor allem wenn man ansonsten eine formularbasierte Authentifizierung macht). X509 Anmeldung ist zwar toller/schicker/sicherer, ist aber schwerer zu handhaben und werden wir wohl so bald nicht in Fhem direkt haben (wer will kanns ja nach wie vor über einen Reverse-Proxy wie bisher auch tun).

Gruß
Julian