Zugriffskontrolle

DokuWiki ist – wie die meisten Wikis – standardmaessig sehr offen. Jeder hat das Recht, Seiten zu erstellen, zu editieren oder zu loeschen. Manchmal ist es trotzdem besser, den Zugriff zu manchen oder allen Seiten zu beschränken. An diesem Punkt kommen Access Control Lists (ACL) ins Spiel. Diese Seite soll einen Ueberblick darueber geben, wie ACL's im DokuWiki arbeiten und wie sie konfiguriert werden.

Fuer weiterfuehrende Informationen oder Fragen –> discussion:acl

WARNUNG: Die ACL-Funktion im DokuWiki ist seit einiger Zeit eingebaut und sollte stabil sein. Trotzdem, wenn Sie sich ueber die Risiken eines unautorisierten Benutzerzugriffs auf die Informationen in ihrem Wiki sorgen, sollten sie diese Information niemals auf einen Rechner stellen, auf den über das Internet zugegriffen werden kann……

Um ACL im DokuWiki zu aktivieren, benoetigen sie zumindest ein Standard-ACL. Kopieren Sie einfach die Beispieldateien jeweils conf/acl.auth.php.dist und conf/users.auth.php.dist nach conf/acl.auth.php und conf/users.auth.php. Danach sollte die Anmeldeseite funktionieren. Wenn Sie die Meldung “No ACL setup yet! Denying access to everyone.” erhalten, dann stellen Sie sicher, dass der Code am Anfang der Datei acl.auth.php die Datei acl.auth.php (steht so im Original) liest und nicht users.auth.php.

Sie benötigen darüber hinaus einige config Optionen. Lassen Sie uns eine Blick auf ein Beispiel werfen, das sie in ihr local.php hinzufügen könnten um die Standard Klartext-Authentifizierung bei der öffentlichen Registrierung zu aktivieren:

  $conf['useacl']       = 1;        // this enables the ACL feature
  $conf['superuser']    = '@admin'; // admin group is superuser

useacl aktiviert das ACL feature. Wenn es aktiviert wurde, erscheint ein Login Feld am Ende jeder Wikiseite, und die Benutzer können sich registrieren. Die superuser Option gibt an, wer in der Lage ist im DokuWiki alles zu machen (inclusive dem Hinzufuegen neuer ACL Beschraenkungen) - dies kann entweder ein einzelner Benutzer oder eine Gruppe sein (gekennzeichnet durch ein führendes @). Wenn Sie ein DokuWiki von Anfang an mit ACL unter Benutzung eines Browsers installieren, klicken Sie den “Login” button, folgen Sie dem “register” Link, und registrieren Sie wenigstens einen Benutzer. (Wenn Sie keinen Registrierungslink sehen, dann sind die Rechte von conf/users.auth.php or conf/acl.auth.php nicht korrekt und deswegen koennen keine neuen Daten dorthin geschrieben werden.) Dann editieren Sie conf/users.auth.php und befoerdern sie wenigsten einen “user” zum “admin”. Ab sofort gibt es einen zusaetzlichen “Admin” button wenn Sie als ein Benutzer angemeldet sind, der zur “admin” Gruppe gehoert.

An diesem Punkt kann eine zusaetzliche Sicherheitsfunktion aktiviert werden. Um Benutzer zu verbieten, sich selber zu registrieren fuegen Sie 'register' zu den disableactions Optionen hinzu:

  $conf['disableactions'] = 'register';        // users are no longer allowed to register themselves

Früher wurde dies mittels der openregister Option gemacht. Dies ist veraltet.

Auf diese Art und Weise koennen Benutzer nur von einem Administrator hinzugefuegt werden (entweder durch das Admin Webinterface oder durch den direkten Eintrag in conf/users.auth.php ).

Darueber hinaus gibt es zusätzliche Konfigurationsoptionen, die Kontrolle ueber andere Aspekte der ACL's erlauben. Viele werden hierfür aber die Standardeinstellungen fuer ausreichend halten.

$conf['autopasswd']  = 1;                //autogenerate passwords and email them to user
$conf['passcrypt']   = 'smd5';           //Used crypt method (smd5,md5,sha1,ssha,crypt,mysql,my411)
$conf['defaultgroup']= 'user';           //Default groups new Users are added to
$conf['profileconfirm'] = '1';           //Require current password to confirm changes to user profile
$conf['authtype']     = 'plain';         // plaintext backend (default)

• Aendern Sie autopasswd auf 0 um dem Benutzer die Auswahl eines eigenen Passwortes zu erlauben. Dies hat allerdings den Seiteneffekt, dass man nicht mehr ueberpruefen kann, ob der Benutzer sich auch mit einer korrekten Emailadresse registriert.
• passcrypt legt die Verschluesselungsmethode fuer das Passwort fest.
• defaultgroup erklaert sich von selbst: alle neuen Benutzer werden zunaechst in diese Gruppe eingetragen.
• Setzen Sie profileconfirm auf 0 um einem angemeldeten Benutzer zu erlauben, sein Profil zu aendern (Name, Passwort und Emailadresse) ohne es mit dem derzeitigen Passwort bestaetigen zu muessen.
• DokuWiki kann verschiedene Wege benutzen um auf Benutzer- und Gruppendaten zuzugreifen. Standardmaessig benutzt es sein eigenes plaintext Verfahen. Das Verfahren wird durch die authtype Option gewaehlt. Siehe hierzu backends um die verfuegbaren Optionen zu sehen.

…

Benutzer koennen hinzugefuegt, geloescht und bearbeitet werden mittels usermanager. Fuer Informationen wie Benutzer manuell hinzugefuegt werden lesen sie die Beschreibung in der plain backend Dokumentation. Standardmaessig koennen sich Benutzer selbst registrieren.

Siehe dazu: FAQ: How to disable open user registration

Zugriffsbeschraenkungen werden mit pages und namespaces verbunden. Es gibt fuenf Zugriffsrechte: read, edit, create, upload und delete (lesen, editieren, anlegen, hochladen und loeschen). Jedes hoehere Zugriffsrecht enthaelt die darunter liegenden. Dabei ist read das unterste und delete das hoechste Recht. Die Rechte create, upload und delete koennen nur namespaces zugewiesen werden.

Wenn DokuWiki prueft, welche Rechte es einem Benutzer geben soll, benutzt es alle Regeln, die mit dem Benutzernamen übereinstimmen oder der Gruppenrechte der Gruppe, in der sich der Benutzer befindet. Die Regel mit dem hoechsten Recht wird benutzt. Die Rechte werden zuerst fuer die Seite geprüft. Danach werden alle übergeordneten namespaces geprueft, bis eine zutreffende Regel gefunden wurde.

Um eine beschraenkende Regel hinzuzufuegen, wechseln Sie auf die Seite, die beschraenkt werden soll und wechseln dann auf die Administrationsoberflaeche durch druecken des Admin Button (Nur verfuegbar fuer den superuser). Dort selektieren Sie Access Control List Management. Ihnen wird dann eine Tabelle wie die folgende gezeigt, die alle Beschraenkungen der ausgewaehlten Seite zeigt.

Beschraenkungen werden in die oberste Zeile der Tabelle eingetragen. Sie muessen einen Bereich auswaehlen. Dies kann entweder die gewaehlte Seite selbst oder einer der namespaces sein, in denen sich die Seite befindet ¹⁾. Sie muessen ausserdem auswaehlen, wem Sie den Zugriff erlauben (oder verbieten) wollen; dies kann eine Gruppe oder ein Benutzer sein. Zum Schluss muessen Sie noch die Rechte waehlen, die Sie gewaehren wollen. Wird nichts gewaehlt, wird der gewaehlte Benutzer oder die gewaehlte Gruppe von der Benutzung der Seite oder des namespaces ausgeschlossen.

Anm.: Das delete-Recht betrifft nur media Dateien. Seiten koennen geloescht (und wieder hergestellt) werden von jedermann, der wenigstens edit-Rechte hat. Jemand der upload-Rechte aber keine delete-Rechte hat, kann existierende media Dateien nicht mehr ueberschreiben.

ALL. Jeder, selbst Benutzer die nicht angemeldet sind, sind Mitglieder der Gruppe ALL. Sie koennen diese Gruppe benutzen, um den Zugriff fuer alle Benutzer zu beschraenken (als Standardeinstellung) um dann die Rechte ausgewaehlter Benutzer zu erweitern. Im Bildschirmfoto oben ist z.B. niemand berechtigt etwas hochzuladen ausser den Mitgliedern der Gruppe UPLOAD.

user. Alle Benutzer, die sich selbst registriert haben sind automatisch Mitglied der Gruppe USER. Benutzen Sie dies, um angemeldeten Benutzern Rechte zu geben. Der Name dieser Gruppe wird durch die Option defaultgroup festgelegt. Anders als die virtuelle Gruppe ALL, ist die Gruppe “user” real. Zu ihr werden alle Benutzer automatisch hinzugefuegt, wenn die einfache Benutzerauthentifizierung benutzt wird. Wenn Sie ein anderes Verfahren verwenden muessen Sie die Gruppen benutzen, die dieses Verfahren benutzt.

Zugriffsbeschränkungen werden in der Datei conf/acl.auth.php gesichert. Sie sollte durch den Webserver geschrieben werden können, wenn Sie die ACL Admin-Oberfläche benutzen wollen. Es wird nicht empfohlen, diese Datei manuell zu editieren. Benutzen Sie die Admin-Oberfläche.

Leere Zeilen und Kommentare im Stile der Shell werden ignoriert. Jede Zeile enthält drei Felder, die durch Leerzeichen getrennt sind:

• Der Name der Ressource. Dies kann entweder ein Seitenname oder ein Namespace sein. Namespaces werden durch ein zusätzliches Sternchen gekennzeichnet (siehe Beispiel unten)
• Eine Gruppe oder Benutzername. Gruppennamen werden mit einem fuehrenden @ Zeichen gekennzeichnet.
• Ein Rechtelevel (siehe unten)

Es gibt 7 Rechtelevel, die durch eine Zahl repräsentiert werden. Höhere Levels beinhalten tiefere. Wenn Sie editieren können, dann können Sie auch lesen. Trotzdem sollte das admin-Recht von 255 nie in der conf/acl.auth.php Datei benutzt werden. Es wird nur intern bei der Prüfung der Übereinstimmung der superuser Option benutzt.

Hier ist ein Beispiel:

*                     @ALL        4
*                     bigboss    16
start                 @ALL        1
marketing:*           @marketing  8
devel:*               @ALL        0
devel:*               @devel      8
devel:*               bigboss    16
devel:funstuff        bigboss     0
devel:*               @marketing  1
devel:marketing       @marketing  2

Lassen Sie uns das Beispiel Zeile für Zeile durchsehen (s. unten für weitere Informationen):

1. Dies setzt Rechte fuer den Haupt-Namespace. Erlaubt jedem, Seiten zu editieren und anzulegen. Trotzdem ist upload nicht erlaubt.
2. Benutzer bigboss werden alle Rechte gegeben.
3. Die Rechte für die Startseite werden für jedermann auf nur-lesen gesetzt.
4. Dann werden die Rechte für den Namespace marketing gesetzt. Allen Mitgliedern der marketing Gruppe wird erlaubt, hier hochzuladen - fuer andere Benutzer gilt Zeile 1, die anlegen und editieren erlaubt. bigboss erbt seine Rechte von Zeile 2, so dass er hochladen und loeschen kann.
5. Der Zugriff auf den namespace devel wird beschraenkt. Niemand darf etwas machen.
6. na gut, nicht wirklich jeder – hier geben wir den Mitgliedern der Gruppe devel volle Rechte
7. und natuerlich darf bigboss alles – er darf sogar hochgeladene Dateien loeschen
8. die devel-Leute wollen aber nicht, dass ihr Boss die funstuff-Seite sieht – erinnern Sie sich: genaue Seitenrechte überschreiben namespace Rechte
9. und das marketing-Team darf auch alles im devel-Namespace lesen
10. und zum Schluss wird den marketing-Leuten erlaubt, die devel:marketing-Seite zu editieren.

Bitte beachten Sie, dass die Reihenfolge in der Datei egal ist. Die Datei wird als Ganzes analysiert und das Wiki sucht die perfekte Übereinstimmung für die Seiten/Benutzer-Kombinationen. Wenn eine Übereinstimmung gefunden wird, wird die Suche abgebrochen. Wenn keine Übereinstimmung gefunden wird, dann werden die Gruppenrechte der zu aktuellen Seite geprüft. Wird auch hier keine Übereinstimmung gefunden, wird die Prüfung mit dem nächsthöheren Namespace fortgesetzt.

Sie sehen im obigen Beispiel die Recht für die Benutzer bigboss. Ihm wurde via Zeile 2 der volle Zugriff gewährt, aber er benötigt den vollen Zugriff auf den devel:* namespace via Zeile 7 noch einmal. Wäre die Zeile nicht da, dann wäre die erste Übereinstimmung für den Benutzer bigboss und Seiten innerhalb des devel Namespace die Zeile 5, weil bigboss Mitglied der magischen Gruppe ALL ist.

Anm.: Um Benutzer und Gruppen mit speziellen Zeichen (wie Leerzeichen) zu konfigurieren müssen Sie den Namen “URL escapen”. Das trifft nur auf spezielle Zeichen im unteren 128 Byte Bereich zu. Die ACL Datei benutzt UTF-8 Codierung. Dadurch kann jedes Multibyte-Zeichen geschrieben werden, wie es ist. Dies trifft nur dann zu, wenn ein Verfahren benutzt wird, dass anders ist als plain – das einfache Verfahren erlaubt keine speziellen Zeichen.