Verständnisfrage - ACL Grundlagen im Code

[dafiesch]

Hallo zusammen

Ich hatte in den letzten Wochen endlich mal etwas Zeit spät Nachts an meiner Stückwerk-Implementierung von Home-Automation zu arbeiten.

ioBroker habe ich dabei als sehr "Einsteiger" freundlich Empfunden, die Lernkurve war flach und die Ergebnisse schnell zu erreichen.

Dafür schon mal großen Respekt, denn das hin zu bekommen bei einer solchen Dynamik und Funktionsvielfalt ist wirklich beeindruckend.

Als ich zu dem Punkt gekommen bin wirklich mal ein paar Sachen steuern zu können wie Heizung, ein paar Rolläden, Lichter etc (evtl werde ich mal noch meine Harmony Scripts und VIS setups posten wenn ich damit zufrieden bin), und die Familienkalender, Webcams usw auf ein Dashboard zusammengezogen hatte wurde es höchste Zeit sich über die Berechtigungsstruktur Gedanken zu machen bevor ich das System für mehr Clients / users / devices öffne.

Von den AuthN / AuthZ Fähigkeiten, die ioBroker im Kern mitbringt war ich zum ersten mal, seit dem ich angefangen hatte, die Plattform zu nutzen einmal nicht begeistert.

Ich hab gesehen dass im Kern Passport läuft - das ist schon mal gut für AuthN (Authentication) - ich hoffe da bald mal ein paar PullRequests stellen zu können damit man so Dinge wie Federation - und damit Potentielle 2FA-Authentifizierung - ins Spiel bringen kann.

Das hilft mir aber mit AuthZ (Authorization) nicht weiter.

Den Ursprung der ACLs im Konzept verstehe ich - ich habe aber leider bisher im durchschauen die Codebasis dafür nicht finden können.

Mich würde interessieren, wie der Aufbau ist und wie abkapselbar das Konzept ist, um zu verstehen ob es Sinn macht, weiter in der Richtung zu schauen.

Wenn ich einen PR machen würde für AuthZ dann würde ich nach Folgendem schauen:

• Berechtigungen mehr nach dem Windowsprinzip - Mehrere Gruppen mit individuellen Rechten pro Eintrag (Objekt oder State)

Vererbung der Rechte (Child erbt automatisch Parent Rechte im Object Tree, also States erben vom Objekt, Objekte von Instanz - falls nicht explizit deaktiviert

Dadurch auch: Massenänderungen von Berechtigungen über iobroker.admin 

Das ist jetzt nur mal so in den Tag (oder eher in die Nacht) gesponnen.. und ich will im ersten Schritt auch erst mal verstehen wie stark verzahnt das Rechtekonzept im Code ist.

Vielleicht kann mich jemand in die richtige Richtung im Code stupsen, das wäre schon mal ein guter Anfang.

Herzlichen Dank vorneweg - Keep automatin'

[apollon77]

Hi,

am besten kann hier Bluefox mit Details aufwarten, aber ich versuch mal mein bisheriges (Halb) Wissen hier zu schreiben.

Generell ist AuthN und AUthZ drin, wird aber von eher wenigen Usern verwendet, ich tippe auf weit unter 1%

AuthN ist korrekt, aktuell primär per Passwort. Das wird in den UI-Adaptern die es unterstützen genutzt aber auch von API-Adapter wie z.B. Simple-API bzw für Verbindungen über socket.io. Man müsste also hier Support für erweiterte bzw zusätzliche AuthN Verfahren (2FA oder so) neben in den Core auch in mehreren Adapter einbauen oder braucht entsprechende Fallback-Konzepte das Passwort auch immer noch parallel tut oder so. Eine spontane Idee wäre dann das noch zu erweitern das man pro User oder Gruppe sagen kann welche Adapter es nutzen dürfen

AuthZ basiert von der Grundidee und Konzept auf Linux ACLs. Es gibt Gruppen, die können Rechte für Objekte und States haben. Auf der Ebene von Objekten definiert man welchem User und zu welcher Gruppe das Objekt gehört.

Wenn es einen Zugriff auf die Daten gibt und ein User Authentifiziert ist dann werden die rechte geprüft und damit festgelegt ob der Zurgiff erlaubt ist oder nicht.

Das ganze wird nicht im reinen Core, sondern im Adapter-Core geprüft, was grob hier ist (also ein Einstiegspunkt): https://github.com/ioBroker/ioBroker.js … r.js#L3359 . Diese Methode wird in allen anderen Funktionen der adapter.js genutzt um Permissions zu prüfen.

Es gibt noch einige methoden die Adapter zusätzlich nutzen können die aber auch in adapter.js drin sind.

Jeder Adapter nutzt diese Funktionen zum Zugriff auf Daten und damit ist das der sinnvolle Punkt. Und damit ist es vor allem anderen sehr gut weggekapselt - einerseits in dieser Methode von oben, andererseits generell in der adapter.js.

Die API muss an der Stelle nach aussen hin stabil und rückwärtskompatibel bleiben.

So, jetzt kommst du ... was brauchst Du noch?

Ingo

PS: Ich schiebe den Thread mal ins Entwickler-Forum.

[dafiesch]

Tausend Dank, das ist auf jeden Fall genau das was ich gesucht habe - ich führ mir das mal zu Gemüte, hab schon einiges interessantes gesehen

[apollon77]

Na da bin ich mal gespannt was du für Ideen hast

Achja: falls du PRs für den js-Controller (zb adapter.js) hast dann mach die bitte gegen den 1.6.0-dev branch. Master ist die 1.5.x die wir demnächst finalisieren müssen, die ist aber Feature complete. Da kämen nur bugfixes rein.

Gesendet vom Handy …

[dafiesch]

Also das wird ne weile dauern, erwarte nicht zu viel

Ich möcht mir erst mal nen Plan von den Zusammenhängen machen und mir überlegen was nicht nur meiner Vorstellung was bringt sondern wie man das eventuell sogar "modular" oder "anpassbar" bekommt

Is ne interessante Abwechslung

[apollon77]

Cool … jede Unterstützung mit so einem Ansatz hilft allen Usern. Find ich super.

Gesendet vom Handy ...

[dafiesch]

So - ich hab heute nach ends-langer Zeit endlich Gelegenheit mich mit dem Thema zu beschäftigen - Familie und Job brauchen meine Aufmerksamkeit

Ich hab mal angefangen ne Dev Umgebung aufzuziehen - aber hatte Ubuntu basiert damit noch so meine Schwierigkeiten - eingerostet schätze ich.

Generell finde ich dass ein HRBAC aktuell für etwas wie IOBroker am geeignesten wäre. Jetzt nicht unbedingt für joe-schmoe, aber das würde hervorragend skalieren für größere Installationen und lässt auch für die Zukunft noch Luft.

Ich glaube ich habe in https://github.com/phellipeandrade/rbac einen guten Anfangspunkt gefunden, basierend auf https://blog.nodeswat.com/implement-acc … 67e7b484d1

das könnte gut als Start dienen - zunächst als Drop-In Replacement für das Owner / Group Konzept aus der Unix / Linux Welt das aktuell verwendet wird um die Wellen klein zu halten und das wäre dann Schritt für Schritt auf ein volles RBAC aufbohrbar.

Ich hab noch meine Probleme damit einen guten Ansatz für ein modulares System zu finden - frage mich auch ob das unterm Strich dann wirklich noch Sinn macht - die Rechteverwaltung ist doch recht tief verwurzelt und ich hab so ganz ehrlich meine Sorgen ob Abstraktionslayer oder Hook-Systeme da nicht mehr bremsen als ermöglichen (wenn 98% eh die selbe Implementierung verwenden).

Generell würde ich mal schauen wann ich wieder Zeit finde, dann das DevEnvironment fertig machen und mal eine Basis-Implementation des HRBAC auf Basis des "rbac" npms zu machen. Im Punkt Abhängigkeiten, Footprint etc sieht das ja mal nicht schlecht aus - Neue Objekte scheinen hier aber einen Rebuild des Permission Trees nach sich zu ziehen.. Ggf. in hoch dynamischen Umgebungen ein Problem - aber da sehe ich die Lösung hier auch nicht.

Hoffe "bald" was neues zum Thema zu haben - wie gesagt aber endlich wieder einmal eine schöne Abwechslung

Guten Rutsch und so