MyCoRe bietet verschiedene Strategien um ACLs für die Beurteilung von Nutzerrechten auszuwerten. Je nach Anwendungslage können diese sehr unterschiedlich sein. Die vom MyCoRe-Kern angebotenen Strategien sind hier beschrieben.
Das ACL-System ist nur lose an das Datenmodell von MyCoRe gekoppelt und so sind ACL-Regeln nicht zwangsweise an MCRObjectIDs gebunden, sondern nehmen als ID jeden String entgegen. Diese Flexibilität kann man sich zu Nutze machen, wenn es um die Überprüfung der Zugriffsrechte geht. Bei MyCoRe gibt es drei vordefinierte Methoden, die über Properties ausgewählt werden.
Diese Methode ist der Standardfall von DocPortal. Zu jeder ObjectID wird die ACL-Regel mit gleicher ID
genommen.
Existiert diese nicht, wird der Zugriff verweigert. Die Pflege der ACL-Regeln, z.B. die Integration von
Standardregeln, übernimmt das SimpleWorkFlow-Modul, das im User Guide beschrieben wird. Dabei wird jedem neu
angelegten Objekt eine objektspezifische Regel angehängt. Beim Einstellen in den MyCoRe-Server, entfernt ein
Eventhandler die dort vorhandene Regeldefinition und legt eine entsprechende Regel für das Dokument an. Methode 1
ähnelt in diesem Zusammenhang der Unix-Rechteverwaltung und dem dort benutzten Befehl
umask
. Änderungen
an den Standardregeln gelten für neu eingestellte Objekte. Folgende Properties sind für Methode 1:
|
|
Diese Methode arbeitet wie Methode 1, nutzt jedoch einen anderen Eventhandler, der nicht für jedes Objekt eine Regel anlegt, sondern diese ignoriert. Das bedeutet, dass man für einzelne Objekte explizit eine Regel anlegen muss oder es tritt beim Überprüfen die erweiterte Behandlung in Kraft. Diese sieht ein Zurückfallen auf die Regel des Objekttyps vor und notfalls die Anwendung einer Standardregel. Die Regel für einen Objekttyp lässt sich über die Kommandozeile anlegen.
|
|
Heißt der Objekttyp
document
, so lautet die ID für das ACL-System
default_document
. Die
Standardregel, die notfalls nach der Objekttyp-Regel überprüft wird, lautet
default
. Beispiele für die
oben genannten Regeldateien (
grant-*.xml
), finden sich in DocPortal unter
config/acl
.
Methode 2 reduziert gegenüber Methode 1 den Verwaltungsaufwand, sowohl auf Administratorseite als auch auf
Datenbankseite, wegen der reduzierten Zahl an Regelzuweisungen. So treten Änderungen an den Standardregeln sofort
für alle entsprechenden Objekte in Kraft.
Folgende Properties sind für die Methode 2:
|
|
Diese Methode arbeitet wie Methode 1, nutzt jedoch wieder den Eventhandler von Methode 2. Entsprechend müssen Regeln für MCRObjectIDs selbst angelegt und gepflegt werden. Sollte für eine MCRObjectID keine ACL-Regel hinterlegt sein, so wird Methode 3 rekursiv mit der MCRObjectID des Vaterobjekts angewandt, bis zu einer MCRObjectID eine ACL-Regel existiert. Sollte es keine ACL-Regel geben, wird der Zugriff verweigert. Methode 3 ähnelt also dem Vererbungsmodell von MyCoRe. Folgende Properties sind für die Methode 3:
|
|
Bei dieser Methode darf der Autor (bzw. eine in den Properties festgelegte Rolle) Dokumente anlegen, bearbeiten und Dateien anhängen, so lange sich dieses Dokument in einem ebenfalls über ein Property festgelegten Zustand (servstate) befindet. Ggf. darf der Autor auch Löschrechte an seinen Dokumenten haben. Ansonsten gilt die Objekt-Typ-Strategie.
|
|
Angehangene Dokumente (Derivate) können zugriffsbeschränkt werden durch Gruppierung über Kategorisierung (Klassifikationen). So kann beispielsweise der Zugriff auf einen IP-Adressbereich oder bestimmte Gruppen eingeschränkt werden. Die aktuelle Implementierung erlaubt, dass die Zuordnung in die Klassifikation direkt im Dokument festgelegt und für alle angehangenen Derivate inkl. deren Dateien gilt. Es wird überlegt, ob eine flexiblere Implementierung sinnvoll ist, die es ermöglicht einzelne Derivate zuzuordnen. Für die Dokumente gilt die Urheber-Strategie.
|
|
Für diese Strategie werden Zugriffsschlüssel vorausgesetzt. Grundsätzlich prüft die Strategie, ob ein Nutzer oder Gast einen passenden persistenten oder temporären Lese -oder Schreibschlüssel für ein Objekt oder Derivat innehat. Sollte ein persistenter und ein temporärer Zugriffsschlüssel vorhanden sein, werden ggf. beide Schlüssel geprüft. Zugriffsschlüssel können für Objekte oder Derivate aktiviert werden:
|
|
Persistente Zugriffsschlüssel können mit folgender Einstellung eingeschränkt werden:
|
|
Hiermit können beispielsweise temporäre Schreibschlüssel auf Leseschreibschlüssel beschränkt werden.
So wird verhindert, dass temporäre Schreibschlüssel aktiviert werden können.
Damit kann beispielsweise die Schreib-Berechtigung gegenüber Gästen verhindert werden.
Um später von temporären Zugriffsschlüsseln etwa im Front-End beispielsweise in Verbindung mit der REST-API profitieren zu können, muss der Attribute-Präfix acckey_
der Zugriffsschlüssel für Session-Attribute im JWT zugelassen werden:
|
|
Diese Strategie ist analog zur Urheber-Strategie (MCRCreatorRuleStrategy), jedoch können explizit ACLs vergeben werden, die dann der Besitzer auf seine Objekte hat. Weiterhin kann über ein Property festgelegt werden, welche Strategie ansonsten gelten soll (MIR.OwnerStrategy.FallbackClass).
|
|