Licensed to be used in conjunction with basebox, only.
// admin
Konnektor-Authentifizierung
Kurzbeschreibung
Wie sich basebox und Ihre Nutzer an angebundenen Systemen anmelden: persönliche Zugangsdaten je Nutzer, gemeinsame Servicekonten, Tokens. Welche Variante ein Konnektor nutzt, entscheidet darüber, wer was sieht – deshalb ist das die wichtigste Sicherheitsfrage bei Konnektoren.
Wofür nutze ich das
Greift der Assistent über einen Konnektor auf ein Wiki, ein Ticketsystem oder ein Postfach zu, muss er sich dort ausweisen. Sie legen als Administrator fest, mit welchem Modell das geschieht, und Sie müssen Nutzern erklären können, warum sie ein Token hinterlegen sollen.
Die drei Modelle
| Modell | Wie es funktioniert | Wer sieht was | Typische Konnektoren |
|---|---|---|---|
| Persönliche Zugangsdaten | Jede Person hinterlegt ein eigenes Zugriffstoken; basebox reicht es bei jeder Anfrage an das System weiter | Genau das, was die Person im System selbst sehen darf | E-Mail (IMAP), DokuWiki, YouTrack, Nextcloud, Atlassian, Roxtra |
| Gemeinsames Servicekonto | Der Administrator hinterlegt ein Konto, das für alle Anfragen verwendet wird | Alle Nutzer sehen, was das Servicekonto sieht | Nur-Lese-Zugänge auf allgemein zugängliche Inhalte, wo der Konnektor das unterstützt |
| Ohne Anmeldung | Kein Konto nötig | – | Rechner; Websuche (die Anfrage geht ohne Nutzeridentität an den Anbieter) |
basebox verwendet nie ein gemeinsames Admin-Token, um Daten abzurufen und sie dann je Nutzer zu filtern. Bei persönlichen Zugangsdaten setzt das angebundene System seine eigenen Berechtigungen durch – ACLs, Rollen, Projektmitgliedschaften –, genau wie bei einer direkten Anmeldung der Person.
Wo finde ich die Einstellung
- Administration → Konnektoren: je Konnektor die Basis-URL, gegebenenfalls ein gemeinsames Servicekonto oder ein API-Schlüssel auf Organisationsebene (etwa für die Websuche), Verbindung testen, Schalter.
- Nutzer: im Chat über das „+"-Symbol bei der Eingabezeile den Konnektor anklicken und dort das persönliche Token eintragen. Alternativ unter Einstellungen → Konnektoren.
Schritt für Schritt
Konnektor mit persönlichen Zugangsdaten einführen:
- Aktivieren Sie den Konnektor unter Administration → Konnektoren und tragen Sie die Basis-URL des Systems ein (auf basebox Server setzt der Platform Operator externe Endpunkte teils per Helm – siehe Konnektoren konfigurieren).
- Klicken Sie auf Verbindung testen.
- Geben Sie den Konnektor in den App-Einstellungen der Apps frei, in denen er nutzbar sein soll.
- Informieren Sie Ihre Nutzer, wie sie ein Token erzeugen – für YouTrack steht die Anleitung unter YouTrack-Token erstellen. Betonen Sie: ein eigens erzeugtes Token, nicht das Login-Passwort.
- Nutzer tragen ihr Token ein und klicken auf Verbindung testen. Erst dann stehen die Werkzeuge des Konnektors in ihrem Chat zur Verfügung.
Gemeinsames Servicekonto einsetzen (wo unterstützt):
Nur für Inhalte, die ohnehin alle Nutzer sehen dürfen – ein öffentliches Wiki, ein allgemeines Handbuch. Legen Sie ein eigenes Konto mit minimalen, lesenden Rechten an; nutzen Sie kein Konto einer echten Person.
Wie Zugangsdaten gespeichert werden
- Nur schreibend. Hinterlegte Zugangsdaten werden nie an den Browser zurückgegeben, in Protokollen ausgeblendet und nie automatisch ausgefüllt. Ein Kennzeichen zeigt lediglich, dass welche gesetzt sind. Auch Sie als Administrator können die Zugangsdaten anderer Nutzer weder sehen noch verwenden.
- Je Nutzer getrennt. Zugangsdaten werden für jede Anfrage frisch anhand der Nutzerkennung geladen; sie werden nicht zwischen Nutzern oder Sitzungen geteilt oder zwischengespeichert.
- Sofort widerrufbar. Wird das Token im angebundenen System zurückgezogen oder das Konto deaktiviert, verliert basebox den Zugriff mit der nächsten Anfrage.
Der vollständige technische Ablauf mit Sequenzdiagramm: MCP-Berechtigungs- und Autorisierungsablauf.
Hinweise
Schreibzugriff bewusst freigeben
Werkzeuge, die im angebundenen System verändern (erstellen, aktualisieren, löschen), sind je App standardmäßig deaktiviert. Aktivieren Sie sie nur dort, wo das gewollt ist, und nur bei Konnektoren mit persönlichen Zugangsdaten – damit jede Änderung der handelnden Person zugeordnet ist.
Hinweis
- Websuche braucht keine Nutzeranmeldung. Optional hinterlegen Sie einen API-Schlüssel Ihrer Organisation beim Suchanbieter; bleibt er leer, läuft die Suche über das gemeinsame basebox-Kontingent. Ein abgelehnter Schlüssel erzeugt einen Fehler, keinen stillen Rückfall. Details: Websuche.
- E-Mail: IMAP-Host, Port und Verbindungstyp setzt der Platform Operator; Postfach-Zugangsdaten geben Nutzer selbst ein und sie gehören in keine Konfigurationsdatei.
- Zugangsdaten erscheinen nie in Produktionslogs; nur auf Log-Level
DEBUGim Rahmen gezielter Diagnoseläufe.
Häufige Fragen
Warum kann ich als Administrator die Zugangsdaten eines Nutzers nicht einsehen? Weil sie nur schreibend gespeichert werden. Das schützt die Nutzer – und Sie.
Kann ich für alle Nutzer ein Token hinterlegen, damit niemand etwas eintragen muss? Nur als gemeinsames Servicekonto, und nur dort, wo der Konnektor das vorsieht und alle dieselben Inhalte sehen dürfen. Für Systeme mit individuellen Rechten ist das der falsche Weg.
Was passiert, wenn ein Nutzer sein Token wechselt? Er trägt das neue Token ein; ab der nächsten Anfrage wird es verwendet. Das alte kann er im Quellsystem widerrufen.
Sieht das angebundene System, dass die Anfrage von basebox kommt? Es sieht eine normale API-Anfrage mit den Zugangsdaten der Person – nicht zu unterscheiden von einer direkten Anmeldung dieser Person.
Benötigen Sie Hilfe? Support kontaktieren