2021.06

Faktenbasiertes Access-System (Neuentwicklung)

Im Rahmen einer Neuimplementierung soll das bestehende (Datenbank-basierte) ACL-System und das darauf aufbauende Stragegy-Konzept durch ein neues System abgelöst werden, welches (ausgehend von einer Regeldatei im XML-Format) Fakten ermittelt und daraus die Zugriffsrechte ableitet.

Konfiguration

Um das neue System zu aktivieren, müssen folgende MyCoRe-Properties gesetzt werden:

1
2
MCR.Access.Strategy.Class=org.mycore.access.facts.MCRFactsAccessSystem
MCR.Access.Class=org.mycore.access.facts.MCRFactsAccessSystem

Außerdem empfielt es sich während der Konfigurationsphase das Log-Level (in der log4j2.xml) für das Package org.mycore.access.facts auf DEBUG zu setzen.

Funktionsweise

Ausgangsbasis ist eine Regeldatei im XML-Format, die sämtliche Zugriffsberechtigungen auf die Dokumente und Objekte des Repositories beschreibt. Sie stellt einen komplexen booleschen Ausdruck dar, in dem einzelne Bedingungen miteinander verknüpft sind.

Ist eine Bedingung wahr, wird dieser Umstand als Fakt in einer Faktenliste vermerkt. Sollte dieselbe Regel an einer anderen Stelle erneut verwendet werden, ist das Ergebnis der Auswertung bereits bekannt und sie wird nicht erneut geprüft.

XML-Regeldatei

Konfiguration

Die komplette Konfiguration des ACL-Systems erfolgt in einer XML-basierten Regeldatei. Mittels boolescher Algebra können darin sämtliche Berechtigungen für die MyCoRe-Anwendung konfiguriert werden. Standardmäßig heißt die Datei rules.xml und befindet sich auf oberster Ebene im Classpath. Es wird empfohlen, sie im Konfigurationsverzeichnis im resources-Ordner der Anwendung abzulegen. Über das Property MCR.Access.RulesURI kann eine andere Regel-Datei konfiguriert werden.

Aufbau der Regel-Datei

Die Beschreibung der Regel-Datei erfolgt in einem einfachen XML-Format.

Ein Beispiel:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
<or>
  <!-- Administratoren dürfen alles -->
  <and>
    <role>admin</role>
  </and>
  <!-- Jedermann kann Dokumente im Status "published" lesen -->
  <and>
    <action>read</action>
    <status>published</status>
  </and>
</or>    

Boolesche Operatoren

Mit den Elementen <and>, <or> und <not> können beliebig tief verschachtelte boolesche Ausdrücke definiert werden. Auch die Regeldatei selbst bildet einen komplexen booleschen Ausdruck. Es wird empfohlen, auf der obersten Ebene die Regeln mit <or> zu verknüpfen und jede einzelne Regel in einem <and>-Block zu definieren.

Aktionen (<action>)

Die drei Standard-Aktionen heißen read, write und delete.

Für Derivate können zusätzlich noch die Aktionen view (Anzeige im Viewer) und preview (Anzeige eines Vorschaubildes) definiert werden.

Aus anderen MyCoRe-Komponenten oder der eigen Anwendung können weitere Aktionen hinzu kommen.
(z.B.: create-user, register-Datacite, ...)

Zielobjekte (<target>)

Access-Regeln können auf folgende Ziele beschränkt werden:
  • metadata (MyCoRe-Objekte)
  • files (Dateien = Inhalte der MyCoRe-Derivate)
  • category (Klassifikationseinträge)
  • webpage (Webseiten = URLs mit statischen Inhalten)
  • solr (SOLR = URLs für SOLR-Requesthandler)
  • restapi (REST-API)

Nutzer, Rollen (<user>, <role>)

Die Regeln können auf bestimmte Nutzer und Rollen beschränkt werden.

Erstellt von (<createdby>)

Für die Person, die das Objekt erstellt hat, können individuelle Regeln definiert werden.

1
2
  <createdby />                        <!-- Objekt wurde vom aktuellen Nutzer erstellt -->  
  <createdby>administrator</createdby> <!-- Objekt wurde vom Administrator erstellt -->  

Klassifikationseintrag (<category>)

Es wird geprüft, ob das Objekt der angegebenen Klassifikation zugeordnet wurde.

Mit dem Attribute idfact kann angegeben werden, dass die Prüfung der Klassifikation für das Derivate (derid) und nicht für das Objekt (objid) erfolgen soll.

1
2
  <category>genre:dissertation</category>  
  <category idfact="derid">derivate_type:fulltext</category>  <!-- Klassifikation im Derivate -->

Status (<status>)

Es wird geprüft, ob im <service>-Bereich des MyCoRe-Objektes der angegebenen Status gesetzt wurde.

Mit dem Attribute idfact kann angegeben werden, dass die Prüfung der Klassifikation für das Derivate (derid) und nicht für das Objekt (objid) erfolgen soll.

1
2
  <status>review</status>  
  <status idfact="derid">published</status>  

Regulärer Ausdruck (<regex>)

Mit diesem Operator können die oben beschriebenen Fakten über reguläre Ausdrücke geprüft werden. Als Fakten stehen beispielsweise die MyCoRe-Objekt-ID (objid) und ggf. die Derivate-ID (derid) zur Überprüfung zur Verfügung.
1
2
3
4
  <regex basefact="objid">mir_mods_.*</regex>
  <regex basefact="user">.*admin</regex>
  <regex basefact="category">ddc:.*</regex>
  <regex>webpage:/content/search/.*_intern.xed</regex>  <!-- default: basefact='id' -->

IPAdresse (<ip>)

Mit diesem Operator kann geprüft werden, ob die IP-Adresse des Nutzers in einer bestimmten IP-Range liegt. zur Überprüfung zur Verfügung.
1
2
  <ip>192.168.0.0/255.255.0.0</ip> <!-- lokales Netzwerk -->
  <ip />                           <!-- default: localhost -->   
Konfigurationsmöglichkeiten
Der Wert der zu prüfenden IP-Adresse/IP-Bereich ist konfigurierbar. Über Properties lassen sich Regeln für verschiedene Anwendungsszenarien umsetzen (z.B. Zugriff nur aus dem Netz der eigenen Institution). Die zu prüfenden IP-Adressen können mit dem MyCoRe-Property-Mechanismus für jede Anwendung individuell konfiguriert werden.
1
2
MCR.Access.Facts.Condition.ip-from-institution=org.mycore.access.facts.condition.fact.MCRIPCondition
MCR.Access.Facts.Condition.ip-from-institution.IP=123.45.0.0/255.255.0.0

Properties: mycore.properties

1
2
3
4
5
<and>
  <action>read</action>
  <target>files</target>
  <ip-from-institution />
</and>

Regel: rules.xml

Beispiele

Es folgen ein paar komplexere Anwendungsszenarien, wie sie in Dokumentenservern vorkommen können:
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
  <or>
    <!-- Alle Dokumente im Status 'published' sind öffentlich zugänglich, 
         außer Dateien von Dokumenten in der Kategorie mir_access:intern
         (Die Metadaten dieser Dokumente sind jedoch frei zugänglich) -->
    <and>
      <status>published</status>
      <action>read</action>
      <or>
        <not>
          <category>mir_access:intern</category>
        </not>
        <target>metadata</target>
      </or>
    </and>
  
    <!-- Editoren dürfen 'alles' für Dokumente im Status 'submitted oder 'embargo' -->
    <and>
      <role>editor</role>
      <or>
        <target>metadata</target>
        <target>files</target>
      </or>
      <or>
        <action>read</action>
        <action>write</action>
        <action>delete</action>
        <action>register-DNBURN</action>
        <action>register-Datacite</action>
      </or>
      <or>
        <status>submitted</status>
        <status>embargo</status>
      </or>
    </and>

    <!-- Alle Webseite sind öffentlich zugänglich, 
         außer Seiten, die auf 'intern.xed' enden -->
    <and>
      <target>webpage</target>
      <action>read</action>
      <and>
        <regexp>webpage:.*</regexp>
        <not>
          <regexp>webpage:/content/search/.*_intern.xed</regexp>
        </not>
      </and>
    </and>
  
    <!-- Der /find-RequestHandler von SOLR ist frei zugänglich -->
    <and>
      <target>solr</target>
      <action>read</action>
      <id>solr:/find</id>
    </and>
  </or>  

Verarbeitung der Regeln

Zu Beginn werden anhand der Anfrage einige Standardfakten gesetzt:
  • id = ID des zu prüfenden Objektes
  • objid = ID des MyCoRe-Objektes (wenn zutreffend)
  • derid = ID des MyCoRe-Derivates (wenn zutreffend)
  • target = Ziel der Prüfung: metadata, files,... (s.o.)

Anschließend wird der boolesche Ausdruck in der Regeldatei verarbeitet. Ergibt eine Regel true, wird das als Fakt vermerkt. Der Name des Faktes entspricht dem Namen der Regel. Mit dem optionalen Attribut fact kann der Faktname geändert werden. Das ist sinnvoll, wenn eine Regel in verschiedenen Zusammenhängen genutzt wird (z.B gleichzeitig für Objekte und Derivate), oder wenn in anderen Regeln (z.B. regex) explizit darauf zugegriffen werden soll.

Einige Regeln (z.B. für Reguläre Ausdrücke) nutzen Fakten aus anderen Regeln. Sollten diese Fakten noch nicht verfügbar sein, versucht das System anhand des Faktnamens zu ermitteln welche Regel für die Bereitstellung des Faktes verantwortlich ist und zieht deren Ausführung vor.

Erweiterbarkeit

Klassen und Interfaces

Klassendiagramm

Abbildung: Klassendiagramm für Factbased Access System

Implementierung

Das System lässt sich einfach um neue Regeln erweitern. Diese sollten die Klasse MCRAbstractFactCondition erweitern. In der Regel ist es dabei ausreichend die Methode computeFact(MCRFacts facts) zu implementieren. Grundlage für die Überprüfung sind Informationen aus der Session, das zu prüfende Objekt und die bereits ermittelten Fakten. Ist das Ergebnis wahr, wird für die Regel ein neuer Fakt in dei Faktenliste eingetragen.

Die neue Regel ist in die mycore.properties einzutragen:

1
  MCR.Access.Facts.Condition.name=org.myapplication.facts.condition.MyConditionImplementation
Der Name im Property entspricht dem Namen des XML-Elements in der Regel-Datei.