2015.05 2016.06

Strategien zur Verwendung von ACL

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.

Zugriffsstrategien

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.

Methode 1: ObjectID

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:

          MCR.EventHandler.MCRObject.1.class=org.mycore.access.MCRAccessEventHandler
          MCR.EventHandler.MCRDerivate.1.class=org.mycore.access.MCRAccessEventHandler
          MCR.Access.Strategy.Class=org.mycore.access.strategies.MCRObjectIDStrategy
        

Methode 2: Objekt-Typ

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.

          update permission read for id default_<objekttyp> with rulefile grant-all.xml
          update permission writedb for id default_<objekttyp> with rulefile grant-admins.xml
          update permission deletedb for id default_<objekttyp> with rulefile grant-admins.xml
        

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:

          MCR.EventHandler.MCRObject.1.class=org.mycore.access.MCRRemoveAclEventHandler
          MCR.EventHandler.MCRDerivate.1.class=org.mycore.access.MCRRemoveAclEventHandler
          MCR.Access.Strategy.Class=org.mycore.access.strategies.MCRObjectTypeStrategy
        

Methode 3: Vererbung von Regeln

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:

          MCR.EventHandler.MCRObject.1.class=org.mycore.access.MCRRemoveAclEventHandler
          MCR.EventHandler.MCRDerivate.1.class=org.mycore.access.MCRRemoveAclEventHandler
          MCR.Access.Strategy.Class=org.mycore.access.strategies.MCRParentRuleStrategy
        

Methode 4: Urheber (Creator)

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.

          MCR.EventHandler.MCRObject.1.class=org.mycore.access.MCRRemoveAclEventHandler
          MCR.EventHandler.MCRDerivate.1.class=org.mycore.access.MCRRemoveAclEventHandler
          MCR.Access.Strategy.Class=org.mycore.access.strategies.MCRCreatorRuleStrategy
          # You can also specify a comma separated list of categories like: state:submitted,state:new
          MCR.Access.Strategy.SubmittedCategory=state:submitted
          MCR.Access.Strategy.CreatorRole=submitter
        

Methode 5: Derivat-Zugriff

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.

          MCR.EventHandler.MCRObject.1.class=org.mycore.access.MCRRemoveAclEventHandler
          MCR.EventHandler.MCRDerivate.1.class=org.mycore.access.MCRRemoveAclEventHandler
          MCR.Access.Strategy.Class=org.mycore.mir.authorization.MIRStrategy
          # You can also specify a comma separated list of categories like: state:submitted,state:new
          MCR.Access.Strategy.SubmittedCategory=state:submitted
          MCR.Access.Strategy.CreatorRole=submitter
        

Methode 6: Zugriffsschlüssel

Es wird geprüft, ob für das Objekt Lese- oder Schreibschlüssel vorhanden sind. Ansonsten gilt die MIRStrategy

          MCR.EventHandler.MCRObject.1.class=org.mycore.access.MCRRemoveAclEventHandler
          MCR.EventHandler.MCRDerivate.1.class=org.mycore.access.MCRRemoveAclEventHandler
          MCR.Access.Strategy.Class=org.mycore.mir.authorization.accesskeys.MIRAccessKeyStrategy
          # You can also specify a comma separated list of categories like: state:submitted,state:new
          MCR.Access.Strategy.SubmittedCategory=state:submitted
          MCR.Access.Strategy.CreatorRole=submitter
          MIR.AccessKeyStrategy.ObjectTypes=mods,derivate
          MCR.URIResolver.ModuleResolver.accesskeys=org.mycore.mir.authorization.accesskeys.MIRAccessKeyResolver
        

Methode 7: Besitzer

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).

          MCR.EventHandler.MCRObject.1.class=org.mycore.access.MCRRemoveAclEventHandler
          MCR.EventHandler.MCRDerivate.1.class=org.mycore.access.MCRRemoveAclEventHandler
          MCR.Access.Strategy.Class=org.mycore.mir.authorization.accesskeys.MIROwnerStrategy
          # You can also specify a comma separated list of categories like: state:submitted,state:new
          MCR.Access.Strategy.SubmittedCategory=state:submitted
          MCR.Access.Strategy.CreatorRole=submitter
          MIR.OwnerStrategy.FallbackClass=org.mycore.mir.authorization.MIRStrategy
          MIR.OwnerStrategy.ObjectTypes=mods,derivate
          MIR.OwnerStrategy.AllowedPermissions=read,writedb
        

 Kathleen Neumann - 2015-09-23