Zugriffskontrolle

Jamdesk bietet Ihnen fünf Möglichkeiten zu steuern, wer Ihre Dokumentation lesen kann. Die meisten Teams entscheiden sich für eine Variante und bleiben dabei; manche kombinieren mehrere.

Den richtigen Ansatz wählen

Häufige Muster

Interne und externe Dokumentation in einem Projekt

Die meisten Teams möchten umfangreiche interne Dokumentation hinter einem Login und daneben eine kleinere öffentliche Website für Kunden. Sie benötigen dafür nicht zwei Projekte. Verwenden Sie den gemischten Modus in einem einzelnen Jamdesk-Projekt:

---
title: Incident Runbook
private: true
---

Seiten mit private: true sind geschützt; alles andere bleibt öffentlich. Alles befindet sich in einem einzigen Repository mit einem Build und einem Dashboard. Der Entsperrbildschirm wird nur angezeigt, wenn ein Leser eine geschützte Seite aufruft.

Für größere interne Bereiche können Sie die Pfade in docs.json auflisten, statt jede Datei zu markieren. Hinweis: auth.password.private[] aktiviert automatisch den Modus für bestimmte Seiten. Fügen Sie daneben nicht enabled: true hinzu (das ist der Modus für die gesamte Website und das Gegenteil von dem, was Sie hier benötigen).

{
  "auth": {
    "password": {
      "hint": "Ask the on-call engineer",
      "private": ["/internal/**", "/admin/runbook"]
    }
  }
}

Zwei separate Projekte

Verwenden Sie nur dann zwei Projekte, wenn die Zielgruppen vollständig unterschiedliches Branding, separate benutzerdefinierte Domains, separate Analysen oder unterschiedliche Tarifstufen benötigen. Beispiele: eine öffentliche Dokumentationswebsite unter docs.acme.com und ein separates internes Wiki unter internal.acme.com. Der Wartungsaufwand ist höher: zwei Builds, zwei Dashboards, zwei Domains.

Benutzerzugriff über den eigenen Login

Wenn Ihre Kunden bereits Konten bei Ihnen haben, ist ein gemeinsames Passwort ein Rückschritt: Es wird weitergegeben, läuft nicht automatisch ab und kann einen Kunden nicht von einem anderen unterscheiden. Bei der JWT-Authentifizierung wird ein angemeldeter Benutzer, der Ihre Dokumentation öffnet, zu einer URL auf Ihrer Seite weitergeleitet. Ihr Backend signiert ein Token und Jamdesk erstellt eine Sitzung für diese Person. Leser benötigen kein Jamdesk-Konto, und es gibt kein gemeinsames Geheimnis, das weitergegeben werden kann.

Das Token kann auch Gruppen enthalten. Fügen Sie groups: ["admin"] zum Frontmatter einer Seite hinzu. Dann können nur Besucher, deren Token admin enthält, die Seite öffnen oder in der Navigation sehen. Alle anderen erhalten einen 404-Fehler, sodass die Seite nicht verrät, dass sie existiert.

---
title: Enterprise audit log API
groups: ["enterprise"]
---

Kombinieren Sie dies mit public-Pfaden für die Teile der Website, die öffentlich bleiben sollen, etwa ein Änderungsprotokoll oder eine Statusseite.

SSO für die Dokumentationswebsite

Mit Enterprise-Tarifen melden sich Leser bei Ihrem Identitätsanbieter (Okta, Google Workspace, Azure AD usw.) an, statt ein gemeinsames Passwort einzugeben. Das eignet sich besonders, wenn Sie ein Prüfprotokoll darüber benötigen, wer welche Inhalte gelesen hat, oder wenn das Deprovisionieren eines Benutzers dessen Zugriff auf Ihre Dokumentation sofort widerrufen muss. Siehe SSO für eine Übersicht und Informationen dazu, wie Sie ein Gespräch mit dem Vertrieb beginnen.

Editoren und Leser

Drei verschiedene Zugriffskonzepte werden manchmal miteinander verwechselt:

Ein Teammitglied kann jede Kombination dieser drei Rollen haben. Sie sind unabhängig voneinander.

Wie geht es weiter?