Copyright © 2022-2026 basebox GmbH, all rights reserved.
Licensed to be used in conjunction with basebox, only.

// admin

Konnektor-Authentifizierung

Diese Seite beschreibt, wie sich basebox und Ihre Nutzer an angebundenen Systemen anmelden: persönliche Anmeldung je Nutzer (OAuth, Token oder Benutzername und Passwort) und gemeinsame Servicekonten. Welche Variante ein Konnektor nutzt, entscheidet darüber, wer was sieht – deshalb ist das die wichtigste Sicherheitsfrage bei Konnektoren.

Der Assistent muss sich am Zielsystem ausweisen

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 meldet sich mit ihrem eigenen Konto an: über OAuth oder mit eigenem Token bzw. Benutzername und Passwort; basebox nutzt diese Anmeldung bei jeder Anfrage an das System	Genau das, was die Person im System selbst sehen darf	E-Mail (IMAP), DokuWiki, YouTrack, Nextcloud, Atlassian, roXtra, Zammad, CentralStationCRM
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, etwa Zammad (gemeinsamer Token) oder roXtra
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.

OAuth ist ein Anmeldeverfahren, kein Konnektor

Bietet ein System OAuth an, meldet sich die Person dort mit ihrem eigenen Konto an und bestätigt eine Freigabe für basebox; basebox erhält diese Freigabe, kein Passwort. Bietet das System kein OAuth an, hinterlegt die Person ihr eigenes Token oder Benutzername und Passwort; basebox zeigt diese Angaben nie wieder an.

Welche Anmeldung ein Konnektor unterstützt, hängt vom Zielsystem ab:

Konnektor	Anmeldung
Zammad	Je Person mit Token oder Benutzername und Passwort, oder ein gemeinsamer Token
CentralStationCRM	Nur je Person mit Benutzername und Passwort
roXtra (in Planung)	Je Person mit Benutzername und Passwort; ein gemeinsamer Zugang ist auch möglich

Netzlaufwerke sind kein Konnektor: basebox verbindet sie beim Server bei der Einrichtung mit einem Zugang für die ganze Organisation, siehe Wissensbasen verwalten.

Zugangsdaten werden an zwei Stellen hinterlegt

• 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.

Konnektoren einführen

Einen Konnektor mit persönlichen Zugangsdaten einführen

1. 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).
2. Klicken Sie auf Verbindung testen.
3. Geben Sie den Konnektor in den App-Einstellungen der Apps frei, in denen er nutzbar sein soll.
4. Informieren Sie Ihre Nutzer, wie sie ein Token erzeugen – für YouTrack steht die Anleitung unter YouTrack-Token erstellen. Wo das System Tokens anbietet, betonen Sie: ein eigens erzeugtes Token, nicht das Login-Passwort. Manche Systeme, etwa CentralStationCRM, kennen nur Benutzername und Passwort.
5. Nutzer tragen ihr Token oder Benutzername und Passwort ein (bei OAuth bestätigen sie die Freigabe im Zielsystem) und klicken auf Verbindung testen. Erst dann stehen die Werkzeuge des Konnektors in ihrem Chat zur Verfügung.

Ein 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.

Schreibende Werkzeuge sind standardmäßig aus

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 DEBUG im 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