3. Rechtekonzept

Kapitel hinzufügen

Die Rechtekonzept und die Zugriffskontrolle basieren prinzipiell auf der objektbezogenen Auswertung einer Rechtezuweisung. Für jedes Objekt wird eine Access Control List (ACL) verwaltet in der für jeden Principal (Benutzer, Benutzergruppe, Rolle) eine Liste mit Berechtigungen (Permissions) verwaltet wird.

Als Erweiterung können Berechtigungen noch mit Bedingungen (Constraints) versehen werden, die ihre Gültigkeit einschränken, z.B. zu welchen Zeiten eine Berechtigung gültig sein soll. Im Folgenden werden die Eigenschaften der Rechtekonfiguration im Detail beschrieben.

3.1 Objekte

Abschnitt hinzufügen

MyBib eL erlaubt die Konfiguration von Zugriffsberechtigungen auf eine Anwendung (Browser, Admin, Editor, Web Service) und auf Dokumente respektive Dokumentenverzeichnisse.

Andere Objekte unterliegen derzeit nicht der Zugriffskontrolle. Für jeden Objekttyp gibt es einen unterschiedlichen Satz von Berechtigungen, z.B. „Run Application“ für Application und „Read Document“ für Document. Bei den Dokumentverzeichnissen gibt es die Besonderheit, dass sich die dort konfigurierten Berechtigungen auch auf die darin befindlichen Dokumente und Dokumentverzeichnisse auswirken bzw. vererben (siehe auch Effektive Berechtigung).

3.2 Principals

Abschnitt hinzufügen

Als Principal wird allgemein ein Subjekt bezeichnet, dem Berechtigungen auf ein oben genanntes Objekt zugeordnet werden kann. Derzeit existieren Benutzer (User), Benutzergruppen (Usergroup) und Rollen (Role).

Benutzer können Benutzergruppen und Rollen zugeordnet werden, wobei ein Benutzer auch gleichzeitig Mitglied von mehreren Gruppen und Rollen sein kann. Ein besonderer Benutzer ist „Anonymous“, der im Fall einer nicht authentifizierten Sitzung verwendet wird. Benutzergruppen können neben Benutzern auch andere Benutzergruppen enthalten, d.h. Benutzergruppen lassen sich hierarchisch organisieren, um z.B. eine Organisationsstruktur abzubilden. Eine besondere Benutzergruppe ist „All Users“ in der alle Benutzer per se Mitglied sind. Eine Rolle kann lediglich Benutzer aufnehmen, wobei sich eine Rolle von einer Gruppe auch noch dahingehend unterscheidet, dass ihre Gültigkeit mit Bedingungen versehen werden kann, z.B. kann eine Rolle „Student“ definiert werden, die nur auf den Arbeitsstationen der Universität aktiv ist.

3.3 Berechtigung

Abschnitt hinzufügen

Bevor eine Aktion auf einem Objekt ausgeführt wird, prüft das System, ob eine entsprechende Berechtigung existiert. Eine Berechtigung kann hierbei explizit erteilt („allow“) oder verweigert („deny“) werden. Auf den verschiedenen Objekttypen können unterschiedliche Aktionen ausgeführt werden, so dass sich die konfigurierbaren Berechtigungen je nach Objekttyp leicht unterscheiden. Für die Anwendungsobjekte sind in der unten stehenden Übersicht die aktuell konfigurierbaren Berechtigungen aufgeführt.

3.4 Bedingungen

Abschnitt hinzufügen

Jede Zuweisung einer Berechtigung kann über eine oder mehrere Bedingungen in der Art eingeschränkt werden, dass eine Berechtigung vom System nur dann berücksichtigt wird, wenn alle Bedingungen erfüllt sind. Andernfalls ist es so, als ob die betreffende Berechtigung erst gar nicht konfiguriert wurde. Die folgende Übersicht führt alle konfigurierbaren Bedingungen auf, wobei nicht jede Bedingung für jede Berechtigung eingestellt werden kann.

• Zeitraum: Zeitraum für den die Bedingung gültig ist
• Arbeitsstation: Arbeitsstation, die in der aktuellen Sitzung verwendet werden muss
• Arbeitsstationengruppe: Gruppe von Arbeitsstationen, die in der aktuellen Sitzung verwendet werden müssen
• Anwendung: Gültig, wenn die aktuelle Sitzung von der angegeben Anwendung initiiert wurde
• Besitzer des Dokuments: Nur bei dokumentbezogenen Berechtigungen und ist dann gültig, wenn der Principal der aktiven Sitzung das Dokument besitzt.
• Metadaten des Dokuments: Nur bei dokumentbezogenen Berechtigungen und ist dann gültig, wenn das Dokument das angegebene Metadatum besitzt
• Seitenbereich: Nur bei dokumentbezogenen Berechtigungen (Lesen, Drucken) und ist dann gültig, wenn die anzuzeigende bzw. zu druckende Seite in dem Seitenbereich liegt
• Zugriffsbeschränkung: Nur bei dokumentbezogenen Berechtigungen (Drucken) und ist dann gültig, wenn die Anzahl der gedruckten Dokumente bzw. Seiten nicht die damit definierten Beschränkungen überschreiten

3.5 Effektive Berechtigung

Abschnitt hinzufügen

Das mit Abstand sicherlich komplexeste Thema ist die Ermittlung der effektiven Berechtigung zur Laufzeit. Der folgende Überblick stellt die Rechteermittlung aus Sicht des Benutzers dar und nicht unbedingt, wie die technische Realisierung exakt im Hintergrund abläuft.

Schritt 1:
Vor der Rechteermittlung werden zunächst alle aktiven Principals der aktuellen Sitzung ermittelt, d.h. welcher Benutzer ist im System für die Sitzung angemeldet, welchen Benutzergruppen und Rollen gehört der Benutzer an, wobei für die Rollen noch die Bedingungen geprüft werden. Als Ergebnis steht eine Liste mit effektiven Principals fest, die im Folgenden bei der Rechteermittlung herangezogen werden.

Schritt 2:
Im nächsten Schritt wird die Berechtigungsliste des Objekts abgerufen und jeder Berechtigungseintrag (Principal → Permission → Constraint) in der vorliegenden Reihenfolge ausgewertet.

Dazu wird zunächst geprüft, ob der Principal der konfigurierten Berechtigung in der Liste der effektiven Principals enthalten ist. Falls nein, wird der Berechtigungseintrag übersprungen. Falls ja, so wird als nächstes geprüft, ob der Berechtigungseintrag die angeforderte Berechtigung enthält. Falls nein, so wird der Berechtigungseintrag auch hier übersprungen. Falls ja, wird dann noch geprüft, ob die Bedingungen der Berechtigungen alle erfüllt sind. Falls nein, so wird die Berechtigung letztlich übersprungen. Falls ja, so wird die Berechtigung als effektive Berechtigung vom System angesehen und die Aktion explizit entweder erlaubt (allow) oder verweigert (deny). Der geschilderte Ablauf ist im Folgenden nochmal schematisch dargestellt.

Schritt 3:
Nun kann es vorkommen, dass durch ausschließliche Betrachtung der Berechtigungsliste des Objektes keine effektive Berechtigung ermittelt werden kann, z.B. weil keiner der Principals in der effektiven Principalliste enthalten ist oder die Bedingungen nicht erfüllt sind. In diesem Fall prüft das System, ob das Objekt zu einem Container gehört, von dem Berechtigungen geerbt werden. So sind bspw. Dokumente immer in Dokumentverzeichnissen organisiert und jedes Objekt auch Teil einer
Anwendung.

Für den Fall, dass in Schritt 2 keine effektive Berechtigung ermittelt werden konnte, wiederholt das System Schritt 2 auf dem Container des Objekts, d.h. für Dokumente auf dem besitzenden Dokumentverzeichnis. Dies wiederholt sich solange, bis der aktuelle Container keinen besitzenden Container mehr hat, z.B. das Wurzelverzeichnis des Dokumentrepositories.

Konnte auch nach Schritt 3 keine effektive Berechtigung ermittelt werden, so wird die angeforderte Berechtigung standardmäßig verweigert.

Besonderheit: Anwendungsbezogene Berechtigung
Eine Besonderheit in der Zugriffskontrolle ist die zusätzliche Auswertung der anwendungsbezogenen Berechtigung, d.h. ob die Sitzung im Rahmen der aktuellen Anwendung berechtigt ist, die Aktion auszuführen. So kann in der Berechtigungskonfiguration für den Browser bspw. das Drucken von Dokumenten (Print Documents) allgemein erlaubt oder verweigert werden. Wird hier das Recht nicht erteilt, so ist das Drucken unabhängig von den objektbezogenen Berechtigungen nicht erlaubt. Die Idee dahinter ist in bestimmten Anwendungsszenarien die Konfiguration der Zugriffskontrolle zu vereinfachen. Wenn z.B. Berechtigungen lediglich nach Benutzergruppen unterschieden werden sollen und nicht mehr pro Objekt separat eingestellt werden müssen.