How to: Einen zweiten Faktor verlangen

Der größte Teil des Wikis ist gewöhnlicher Inhalt, ein Namensraum ist es nicht — Personaldaten, Zugangsmittel, Sitzungsunterlagen. Der zweite Faktor soll Bedingung für den Zugang dorthin sein, ohne dass jede Anmeldung im ganzen Wiki durch eine Abfrage muss.

Das ist Richtlinie, nicht Anmelde-Erzwingung, und der Unterschied entscheidet über das Ergebnis:

Die Richtlinie wird während DokuWikis eigener Rechteprüfung ausgewertet. Damit greift sie auf jedem Weg zum Inhalt — Seitenaufruf, Suchtreffer, Ausgabe, Einbettung durch ein anderes Paket — statt nur dort, wo jemand daran gedacht hat, eine Sperre einzubauen.

Für einen Namensraum — Verwaltung → Zweiter Faktor (do=admin&page=wkidentity), Reiter Namespaces. Ein Namensraum-Präfix je Zeile. Getroffen wird die Kennung selbst und alles darunter; ein leerer Eintrag wirkt nicht als Platzhalter für das ganze Wiki.

Für eine Gruppe oder ein einzelnes Konto — diese Geltungsbereiche schreibt der Verwaltungsbildschirm nicht. Sie stehen in conf/wkidentity-policy.json unter required_scopes:

{
  "required_scopes": [
    { "type": "group",     "id": "redaktion",    "requirement": "MFA_ANY" },
    { "type": "user",      "id": "mmustermann",  "requirement": "TOTP" },
    { "type": "namespace", "id": "intern:personal", "requirement": "MFA_ANY" }
  ]
}

Zulässige Stufen: MFA_ANY (irgendein eingerichteter Faktor), TOTP, MAIL_OTP, AUTHENTICATED. Die Datei trägt daneben die Listen des Verwaltungsbildschirms; vor jedem Überschreiben wird eine Sicherung angelegt.

Auflösung bei mehreren Treffern: Namensraum, dann Gruppen, dann Konto — der speziellere Geltungsbereich gewinnt. Verlangen zwei Quellen zwei verschiedene bestimmte Faktoren, gewinnt der speziellere, und der Widerspruch wird vermerkt.

Was ein abgewiesener Leser sieht: keine nackte Verweigerung, sondern einen von zwei Gründen mit dem jeweils passenden Weg —

• nicht eingerichtet — Verweis auf die Einrichtung im Profil;
• eingerichtet, aber in dieser Sitzung nicht bewiesen — Verweis auf eine Aufstufung, die nach korrektem Code auf die ursprüngliche Seite zurückkehrt.

• Erst einrichten lassen, dann verlangen. Eine Richtlinie über einen Namensraum, dessen Nutzer noch keinen Faktor haben, sperrt sie sofort aus. Ankündigen, einrichten lassen, dann setzen.
• Ein frisch eingeladenes Konto ist der Sonderfall dieser Regel. Es existiert vor dem Einlösen nicht und kann deshalb nicht vorher einrichten. Wer will, dass es ohne Faktor nichts erreicht, setzt die Pflicht auf seine Gruppe: Der Geltungsbereich group wird bei jeder Rechteprüfung mit ausgewertet, unabhängig vom Namensraum. Die erste Seite nach dem Anmelden ist dann die Abweisung mit dem Verweis auf die Einrichtung.
• Der Nachweis verfällt. assurance_ttl (Vorgabe 3600 Sekunden) bestimmt, wie lange eine abgeschlossene Aufstufung — oder ein beim Anmelden bewiesener Faktor — als Absicherung dieser Sitzung zählt. Danach fällt die Sitzung auf angemeldet zurück; die Anmeldung selbst bleibt bestehen.
• Richtlinie und Anmelde-Erzwingung sind unabhängig. Eine Pflicht je Konto oder Gruppe wirkt, ob enforce_login an ist oder nicht. So lässt sich ein Faktor von wenigen Konten verlangen, ohne die Anmeldung für alle zu ändern.
• Einen Weg hinein freihalten. Eine Richtlinie, die den Namensraum mit den eigenen Wiederherstellungsnotizen abdeckt, ist eine Falle.
• Das ist keine Verschlüsselung. Ein zweiter Faktor regelt den Zugang durch das Wiki. Die Seitendateien auf der Platte, in einer Sicherung oder im Suchindex schützt er nicht.
• Den Hinweis nicht unterdrücken. Eine Abweisung ohne Weg zur Einrichtung ist eine Sackgasse; Grund und Banner existieren genau dafür.

• Überblick
• Tutorial: Einen zweiten Faktor einrichten und beim Anmelden verlangen
• How to: Jemanden einladen, der noch kein Konto hat
• Fehlerdiagnose