In Notes gibt es viele Stufen, um Daten vor unzulässigem Zugriff zu schützen. Das geht vom Domino Server bis runter zu einzelnen Masken-Feldern. In diesem Beitrag wollen wir uns eingehender mit den Ebenen in der ACL (Access Control List – Zugriffskontrollliste) beschäftigen und wofür wir sie einsetzen können.

Folgende Ebenen stehen uns im Feld „Access/Zugriff“ zur Verfügung.

 Abbildung 1: Eine Zugriffskontrollliste / ACL

 

Manager

Vollzugriff auf die Anwendung inklusive Durchführung von ACL-Änderungen und dem Löschen der Anwendung. Diese Ebene wird normalerweise für Administratoren oder IT-Personal reserviert, um umfassende Kontrollmöglichkeiten zu haben.

 

Designer / Entwickler

Die Anwendung kann in Bezug auf das Design (also die Optik und Programmierung) geändert werden. Designer dürfen die ACL nicht verändern oder die Anwendung löschen. Diese Ebene sollte Entwicklern oder auch dem Ersteller zugewiesen werden.

 

Editor

Dokumente dürfen erstellt und alle Dokumente dürfen geändert oder gelöscht werden. Also sowohl diejenigen, die sie selbst, als auch diejenigen, die andere Nutzer erstellt haben. Diese Ebene sollte denen zugewiesen werden, die mit der Inhaltsverwaltung der Anwendung betraut sind.

 

Author / Autor

Dokumente dürfen erstellt und selbst erstellte dürfen geändert oder gelöscht werden. Diese Ebene sollte den Mitarbeitern, die in dieser Anwendung arbeiten, zugewiesen werden.

 

Reader / Leser

Ermöglicht einen Lesezugriff auf die Anwendung. Dokumente dürfen nicht geändert oder gelöscht werden. Diese Ebene sollte Mitarbeiter zugewiesen werden, die nicht direkt mit der Anwendung arbeiten, aber Informationen von der Anwendung brauchen.

 

Depositor/Einlieferer

Eine Anwendung kann geöffnet werden, es können Dokumente erstellt werden, aber diese werden nicht angezeigt. Diese Ebene könnte für externe Mitarbeiter genutzt werden, die keinen Einblick auf weitere Daten brauchen oder für Umfragen – jeder kann seine Stimme abgeben, aber weder die eigene noch fremde Antworten sehen.

 

No Access / Kein Zugriff

Es ist kein Zugriff auf die Anwendung möglich. Anwendern würde es nicht einmal gelingen, das Anwendungssymbol zum Workspace hinzuzufügen. Diese Ebene sollte Standard für die ACL-Einträge „Default“ und „Anonymous“ sein.

 

Merke: Jede höhere Zugriffsebene erbt alle Rechte der niedrigeren Ebenen!
Ausnahme bildet hier nur die Ebene Reader/Leser (darf im Gegensatz zu Depositor / Einlieferer keine Dokumente erstellen)

 

Weitere Informationen erhaltet ihr auf der folgenden HCL-Homepage. Wie wir in unserem Artikel über die Unterschiede zwischen CCB, CCX und kostenlosen Gast-User-Lizenzen bereits erwähnt haben, ist die Betrachtung dieser unterschiedlichen Zugriffsrechte wichtig für die Entscheidung, welche Lizenzen ihr wirklich benötigt.

Abbildung 2: Zugriffsstufen für die einzelnen Nutzertypen (Quelle: HCL)

 

Vor allem die Schwelle zwischen Autor- und Editorrechten zieht für externe Nutzer immer die Frage nach sich: brauche ich für die Anwendung schon eine CCB-Lizenz (also Editorrechte) oder reicht mir eine CCX-Lizenz, mit der ich nur meine eigens erstellen Dokumente bearbeiten und löschen kann.

 

Darüber hinaus sollte man sich eine Anwendung, die (auch) von externen Nutzern verwendet wird, im Hinblick auf die Gastuser genau anschauen. Dies verdeutlichen wir einmal an dem Beispiel eines Webshops:    

Wenn Ihr eine Shop-Anwendung habt, auf die eine schwer zu schätzende / unbegrenzte Anzahl an externen Usern zugreifen soll, könnt ihr schwierig mit CCX-Lizenzen arbeiten, weil ihr nicht wisst, wie viele ihr benötigt. Wenn ihr dazu also die kostenlosen, in den CCB-Lizenzen enthaltenen, Gastuser nutzen wollt, habt ihr zwei Möglichkeiten:

1. Ihr gebt den Anonymous Usern Autorenzugriff auf die Anwendung. So können sie ohne Anmeldung (dementsprechend aber auch ohne ein Benutzerkonto) Bestelldokumente erstellen, bearbeiten und löschen. Dazu benötigen Sie aber auch immer die konkreten Links zu den Dokumenten. Sie können nicht in die Anwendung gehen und sich alle von ihnen erstellten Dokumente anzeigen lassen, da die Anwendung gar nicht weiß, welche Dokumente von ihnen erstellt wurde, weil sie sich ja nicht gegen die Anwendung/den Server authentifizieren.  

2. Ihr versucht euch an einem Webshop, der nur mithilfe von Einlieferer- und Leserrechten arbeitet und demnach auch authentifizierten Gastusern (Known Guests) das Arbeiten mit der Anwendung erlaubt. Die Erläuterung einer derartigen Rechtestruktur würde aber den Rahmen dieses Artikels deutlich sprengen.  

Bei überschaubarem Nutzerkreis solltet ihr die Nutzer eures Webshops mit CCX-Lizenzen ausstatten, da diese sich dann ein Benutzerkonto einrichten können und im Gegensatz zu den Known Guests, die nur entweder Reader oder Depositor-Rechte haben, auch Autorenzugriff auf ihre Dokumente haben und sie somit im Nachhinein ihre Bestellungen noch verändern oder löschen können.

 

Wir hoffen, dass wir euch das Thema „Zugriffsebenen in HCL Notes/Domino“ mit diesem Beitrag gut verständlich machen konnten. Habt ihr Fragen oder Anregungen? Ruft uns an unter 05251-288160 oder schreibt uns eine Mail an info@itwu.de.

 

Neues vom ITWU-Blog

DOMI im Verse-Kalender 3.2.1 und unsere Roadmap in Sachen Teams@Notes und MS O365-Integrationen - Weiterlesen
ITWU-Projektvorstellung: Ohne Papierkram auf Montage – ITWU zeigt euch das perfekte Tool für euren Montagearbeitsbericht, digital und doch offline-fähig!  - Weiterlesen
Der Grid-Konfigurator – Teil 2 – Wie ihr in ISIE eine Datenbank hinterlegt und eine neue Grid-Konfiguration erstellt - Weiterlesen
LotusScript-Fehler beim Hochladen aus HCL Notes ins Office 365 - Weiterlesen
Verbesserung der Benutzererfahrung auf dem Smartphone mit Nomad - Weiterlesen
ITWU verabschiedet sich am Freitag, den 22.12.2023 in die Winterpause - Weiterlesen
Update-Info: Die neuen Features von HCL Notes Domino 14 - Weiterlesen
 zum Archiv