Lade...
 

MorphIT Berechtigungssystem

Berechtigungssystem in MorphIT

4.2.0

Der Server bietet über die Methode MorphITServerCommand den verbundenen ClassiX-Instanzen eine Schnittstelle an, um direkt mit dem MorphIT-Server zu kommunizieren. Um zu entscheiden, ob eine ClassiX-Instanz einen Befehl ausführen darf, weist der Server den Instanzen Rollen zu, welche die Berechtigungen der ClassiX-Instanzen steuern. Durch diesen Mechanismus können bestimmte ClassiX-Instanzen in ihren Rechten eingeschränkt werden und so kann zum Beispiel eine ClassiX-Instanz gestartet werden, die andere ClassiX-Instanzen nicht beenden darf (shutdown_classix) oder keine weiteren Instanzen starten kann (launch_dedicated_classix).

Die Befehle RequestMorphITBinding und LaunchDedicatedClassiX sind im Server intern ebenfalls als Serverbefehle realisiert und unterliegen den gleichen Berechtigungseinschränkungen wie die dazugehörigen Serverbefehle.

Die Berechtigungen weden in der config.js im Feld permissions konfiguriert. Die vorkonfigurierten Berechtigungen erlauben allen verbundenen ClassiX-Instanzen alle Befehle auszuführen.

 

Berechtigungen

Berechtigungen sind in MorphIT durch Punkte hierarchisch strukturierte Bezeichner, die in Rollen vergeben (allow) oder entzogen (deny) werden können.

Beispiele:

server_command.launch_dedicated_classix
server_command.request_binding
server_command.request_binding.grant_role.user
server_command.shutdown_classix.role.local

 

Innerhalb der allow und deny-Listen gibt es folgende Kurzschreibweisen, die die Definition der Berechtigungslisten vereinfachen:

Listen

In jeder Berechtigung können durch geschweifte Klammen gemeinsame Teile "ausgeklammert" werden.

Beispiel: 

server_command.shutdown_classix
server_command.request_binding
server_command.launch_dedicated_classix

Diese Berechtigungen können auch kürzer wie folgt geschrieben werden:

server_command.{shutdown_classix,request_binding,launch_dedicated_classix}

 

Die Listen sind nicht an eine Stelle beschränkt. Es kann mehrere Listen innerhalb einer Berechtigung geben, die dann "ausmultipliziert" werden.

{a,b}.{d,e,f}

wird zu:

a.d
a.e
a.f
b.d
b.e
b.f

 

 

Zudem sind innerhalb der Listen unterschiedlich geschachelte Bezeichner erlaubt.

a.{b,c.d}.e

wird zu:

a.b.e
a.c.d.e

 

Die Listen können auch verschachelt werden.

a.{b,c.{d,e}}

wird zu:

a.b
a.c.d
a.c.e

 

Die Listen müssen nicht zwangsläufig an den Elementgrenzen des Bezeichners ausgerichtet sein und können zudem leere Elemente enthalten, sodass folgende Definition syntaktisch korrekt (wenn auch schwer lesbar) ist.

a{,.{c,d,e},bc}

Wird zu:

a
a.c
a.d
a.e
abc

 

Wildcards

Am Ende der Berechtigungen sind zusätzlich Wildcards (.*) erlaubt. 

Eine Berechtigung a.* erteilt unter anderem folgende Berechtigungen:

a
a.a
a.b
a.b.c

jedoch nicht:

ab
abc

 

Um einer Rolle die Berechtigung zuzuteilen, alle Server-Befehle auszuführen, reicht die Berechtigung: server_command.*

Zudem gibt es noch das globale Wildcard:

*

Hiermit werden alle möglichen Berechtigungen vergeben (in allow) oder verweigert (in deny).

 

Listen und Wildcards sind auch combinierbar.

a.{b.*, c.d}

Wird zu:

a.b.*
a.c.d

 

Rollen

Die Berechtigungen werden in Rollen zusammengefasst und Rollen werden in Kategorien gruppiert. Die Kategorie system ist vordefiniert, weitere Kategorien sind frei definierbar. Die Rollen müssen dabei Kategorieübergreifend eindeutige Namen haben, da die Kategorie nicht Teil des Rollenbezeichners ist.

Rollen können über bestimmte Serverbefehle den ClassiX-Instanzen zugewiesen werden (Beispiel: request_binding).

Rollen können im Namen analog zu Berechtigungen durch einen Punkt im Namen struktiert werden (Beispiel: "user.admin"). Diese Strukturierung kann verwendet werden, um in inherits per "user.*" alle User-Rollen in einer Rolle zu überschreiben.

Eine Rolle wird als Objekt mit folgenden optionalen Eigenschaften definiert.

Feld Typ Beschreibung
allow Array Definiert die Berechtigungen, die durch diese Rolle erteilt werden. Diese Berechtigungen können innerhalb von deny wiederum eingeschränkt werden. Wildcards sind hier erlaubt (Bsp: server_command.* um alle Server-Befehle zu erlauben)
deny Array Definiert die Berechtigungen, die durch diese Rolle verweigert werden. Hier können Berechtigungen entzogen werden, die in einer anderen Rolle mit allow erteilt wurden. Das heißt auch, dass eine Rolle, die folgendes definiert:
"deny" : [ "*" ]

 Dem Prozess alle Berechtigungen verweigert unabhängig davon, welche anderen Rollen er noch hat. Auch hier sind Wildcards erlaubt.

overwrites Array|string

Gibt an, welche Rolle(n) durch diese Rolle überschrieben werden. Bei überschriebenen Rollen wird allow, deny und inherits ignoriert. Eine überschriebene Rolle kann trotzdem andere Rollen überschreiben und deren allow, deny und inherits dadurch deaktivieren.

Konkret heißt das, dass sich zwei Rollen gegenseitig überschreiben können und in dem Fall keine der beiden Rollen die Berechtigungen des Prozesses beeinflusst.

Wildcards sind nach einem Punkt erlaubt ("user.*" ist erlaubt, "user*" nicht). Ein Sonderfall ist das Wildcard "*", mit dem alle anderen Rollen überschrieben werden. Gibt es zwei Rollen mit "*" in overwrites, dann werden keine Rollen angewandt, da alle Rollen überschrieben werden. Der Prozess hat dann keine Berechtigungen.

inherits Array|string

Gibt die Rolle(n) an, von denen diese Rolle abgeleitet ist. Das heißt, dass deny und allow und inherits dieser Rolle(n) ebenfalls ausgewertet wird.

overwrites der durch inherits eingebundenen Rollen wird nicht ausgeführt. Wird also von einer Rolle per inherits abgeleitet, die eine andere Rolle durch overwrites überschreibt, dann wird dieses overwrites nur dann ausgewertet, wenn die überschreibende Rolle eine echte Rolle des Prozesses ist und nicht nur eine geerbte Rolle.


Da die Anwendung von deny und allow keine Ordnung der Rollen untereinander vorraussetzt, definiert auch inherits keine Ordnung und zyklen innherhalb von inherits sind erlaubt. In dem Fall werden alle Rollen des Zyklus auswertet.

Wildcards sind hier nicht erlaubt.

Auswertung

Ein Prozess kann 0-n Rollen haben. Ein Prozess ohne Rollen hat auch keine Berechtigungen. Praktisch gibt es in MorphIT keine Prozesse ohne Rollen, weil der Server jedem Prozess mindestens 2 Systemrollen zuweist.

Für die Prüfung, ob ein Prozess mit n Rollen eine bestimmte Berechtigung hat, werden aus diesen Rollen alle Rollen entfernt, die durch overwrites überschrieben wurden. Anschließend werden von den verbleibenden Rollen die über inherits geerbten Rollen in die Menge der Rollen aufgenommen und dann werden die allow-Listen aller Rollen zu einer Gesamtwhitelist vereint und die deny-Listen aller Rollen zu einer Gesamtblacklist. Damit ein Prozess eine bestimmte Berechtigung hat, muss diese in der Gesamtwhitelist vorkommen und darf nicht nicht der Gesamtblacklist vorkommen.

Parametrisierte Rollen

Parametrisierte Rollen bieten die Möglichkeit, dynamisch neue Rollen aus einer Vorlage zu generieren. Eine parametrisierte Rolle hat einen regulären Rollenbezeichner. Einzelne Rollensegmente (durch Punkt getrennt) können durch Rollenparameter ersetzt werden (Bezeichner mit vorangestelltem @). Sobald eine Rolle mindestens einen Rollenparameter enthält, handelt es sich um eine parametrisierte Rolle.

Beispiele:

user.@id
location.@state.@city.@street
user.@id.admin

Auf die @-Parameter kann man sich in der Rollendefinition anschließend in allow, deny, overwrites und inherits beziehen. Zusätzlich zu den definierten Parametern gibt es den immer definierten Parameter @self, der den vollen Namen der Rolle enthält.

Beispieldefinition:

"user.@id": {
  "allow":["server_command.shutdown_classix{,.role.@self}"]  
},
"location.@state.@city.@street": {
  "allow":["@state", "@city", "@street"]
},
"user.@id.admin": {
  "inherits":"user.@id",
  "allow":["server_command.shutdown_classix.role.*"]
}

 

Wird nun Beispielsweise im Serverbefehl request_binding die Rolle client.12345 an eine gestartete ClassiX-Instanz vergeben, dann  kann diese nur sich selbst und andere ClassiX-Instanzen beenden, die genau die gleiche Rolle haben (@self wird in dem Fall zu client.12345 ausgewertet). Eine Instanz mit der Rolle client.32546 könnte sie nicht beenden. Auf diese Weise lassen sich die ClassiX-Instanzen gruppieren und gegeneinander abschotten, wenn sie sich nicht gegenseitig beeinflussen sollen.

Durch die hierarchische Strukturierung der Rollen kann eine Rolle mit der Berechtigung: server_command.shutdown_classix.role.client.* alle Instanzen beenden, welche die parametrisierte Client-Rolle haben unabhängig von den Parametern.

 

Systemrollen

Systemrollen sind alle Rollen innerhalb von permissions.roles.system. Diese werden vom MorphIT-Server automatisch anhand der Verbindungsparameter vergeben und sind durch die ClassiX-Instanzen nicht beeinflussbar.

Es gibt folgende Systemrollen:

Systemrolle Beschreibung
local Die ClassiX-Instanz läuft auf der gleichen Maschine, wie der MorphIT-Server. (schließt remote aus)
remote

Die ClassiX-Instanz läuft auf einer anderen Maschine als der MorphIT-Server. (schließt local aus)

interactive

Die ClassiX-Instanz wurde von Nutzer manuell gestartet und hat sich mit dem MorphIT-Server verbunden. (schließt background aus)

background Die ClassiX-Instanz wurde durch einen MorphIT-Launcher gestartet. (schließt interactive aus)
prelaunched Die ClassiX-Instanz wurde auf Anweisung des MorphIT-Servers vorgestartet. (schließt dedicated und interactive aus)
dedicated Die ClassiX-Instanz wurde als Dedizierte Instanz gestartet. (schließt prelaunched und interactive aus)
webservice Die ClassiX-Instanz wurde vom MorphIT-Server als Webservice-Instanz ausgewählt.
webwidget Die ClassiX-Instanz stellt aktuell ein natives WebWidget dar.

InstantView