Licensed to be used in conjunction with basebox, only.
// integration
MCP-Berechtigungs- und Autorisierungsablauf
Gilt für
Produkt: Cloud · Server · Zielgruppe: Entwickler / Integrator · Sicherheitsprüfer
Diese Seite erklärt auf technischer Ebene, wie basebox sicherstellt, dass jeder Nutzer nur Daten sehen und abrufen kann, die er in einem angebundenen System bereits sehen darf – etwa Roxtra, YouTrack, DokuWiki oder jeder andere MCP-Konnektor.
Die kurze Antwort: basebox ist transparent. Es verwaltet oder repliziert die Zugriffsrechte des angebundenen Systems nie. Stattdessen reicht es bei jeder einzelnen Anfrage die eigenen Zugangsdaten des Nutzers an das angebundene System weiter, sodass immer dessen eigenes Berechtigungsmodell gilt.
Das Kernprinzip
Ruft der Assistent ein Werkzeug auf einem angebundenen System auf, tut er das als dieser Nutzer, mit dessen eigenem Token oder Zugangsdaten. basebox verwendet nie ein gemeinsames Admin-Token, um Daten abzurufen und sie dann zu filtern. Das angebundene System erhält eine Anfrage, die von einer direkten Anmeldung dieses Nutzers nicht zu unterscheiden ist – und setzt seine eigenen Berechtigungen entsprechend durch.
Das bedeutet:
- Ein Nutzer in Roxtra mit Nur-Lese-Zugriff auf Projekt A kann über basebox nur Dokumente aus Projekt A abrufen. Das setzt Roxtra durch, nicht basebox.
- Ein Nutzer ohne Zugriff auf einen Confluence-Bereich erhält über basebox dieselbe Antwort „nicht gefunden" oder „Zugriff verweigert" wie beim Öffnen von Confluence im Browser.
- basebox fügt keine neuen Rechte hinzu und nimmt keine bestehenden weg (außer dass Schreibwerkzeuge standardmäßig deaktiviert sind).
Ablauf: Ein Werkzeugaufruf vom Chat zum angebundenen System
Das folgende Diagramm zeigt den vollständigen Lebenszyklus eines einzelnen Werkzeugaufrufs – vom Moment, in dem ein Nutzer eine Chat-Nachricht sendet, bis zur Rückgabe der Antwort des angebundenen Systems.
sequenceDiagram
autonumber
actor User as Nutzer (Browser)
participant Frontend as basebox-Frontend
participant basebox as basebox (MCP-Gateway)
participant DB as basebox-DB
participant MCP as MCP-Server
participant Ext as Angebundenes System (z. B. Roxtra)
User->>Frontend: sendet Chat-Nachricht
Frontend->>basebox: POST /v1/chat (Bearer)
basebox->>basebox: Bearer validieren (Keycloak), user_id extrahieren
basebox->>DB: Nutzereinstellungen für user_id laden
DB-->>basebox: Zugangsdaten je Nutzer (Tokens) + Aktivierungs-Flags
basebox->>DB: Werkzeugeinstellungen laden (welche Werkzeuge diese KI-App freigibt)
DB-->>basebox: erlaubte Werkzeugliste für diese App
basebox->>basebox: ToolAccessControl bilden<br/>(Schnittmenge: Nutzer aktiviert UND App aktiviert)
basebox->>basebox: Werkzeuge + Prompt an das LLM senden
basebox-->>Frontend: Stream: LLM entscheidet, ein Werkzeug aufzurufen
basebox->>basebox: Nutzer-Zugangsdaten in connection_config einfügen<br/>(erzeugt Authorization-Header für diesen Nutzer)
basebox->>MCP: POST /mcp mit Authorization: Bearer <user_token>
MCP->>Ext: API-Aufruf mit Authorization: Bearer <user_token>
Ext-->>MCP: Daten, die der Nutzer sehen darf
MCP-->>basebox: Werkzeugergebnis (als Daten gerahmt, nicht als Anweisungen)
basebox-->>Frontend: Stream: Werkzeugergebnis + finale LLM-Antwort
Frontend-->>User: Antwort des AssistentenSchritt-für-Schritt-Erklärung
Schritte 1–3 – Nutzerauthentifizierung in basebox. Der Browser des Nutzers sendet mit jeder Anfrage ein Keycloak-JWT. basebox validiert dieses Token und extrahiert die user_id. So weiß basebox, wer fragt.
Schritte 4–5 – Zugangsdaten je Nutzer laden. basebox fragt die Tabelle settings für genau diese user_id ab. Jede Zeile speichert die Zugangsdaten, die dieser Nutzer für einen Konnektor eingegeben hat. Für alle Konnektoren, die Authentifizierung verlangen, fragt basebox nach einem dedizierten API-Token (einem widerrufbaren, begrenzten Zugriffstoken, das das angebundene System erzeugt) – nicht nach dem Login-Passwort des Nutzers. Das primäre Passwort des Nutzers wird damit zu keinem Zeitpunkt in basebox gespeichert. Das Token wird so gespeichert, wie es eingegeben wurde, und nie mit anderen Nutzern geteilt.
Schritte 6–7 – App-Werkzeugeinstellungen laden. Eine basebox-KI-App (Chat-Assistent) kann so konfiguriert sein, dass sie nur eine Teilmenge der Werkzeuge freigibt. basebox lädt diese Liste und bildet die Schnittmenge: Ein Werkzeug ist in dieser Chat-Sitzung nur verfügbar, wenn sowohl der Nutzer diesen Konnektor aktiviert hat (mit Zugangsdaten) als auch die KI-App dieses Werkzeug freigibt.
Schritt 8 – Werkzeug-Zugriffskontrolle. Das ist das Gate. Ein Werkzeug wird dem LLM nur präsentiert, wenn der Nutzer eigene Zugangsdaten für diesen Konnektor hinterlegt hat. Hat der Nutzer den Konnektor nie konfiguriert, erscheinen keine Werkzeuge daraus. Sind die Zugangsdaten des Nutzers ungültig oder widerrufen, lehnt das nachgelagerte System den Aufruf ab.
Schritte 9–10 – LLM wählt ein Werkzeug. Das LLM erhält die erlaubte Werkzeugliste. Es entscheidet, ein Werkzeug aufzurufen. basebox fängt das vor der Ausführung ab.
Schritt 11 – Einfügen der Zugangsdaten. basebox nimmt die gespeicherten Zugangsdaten des Nutzers und fügt sie in die Verbindungskonfiguration für diesen Werkzeugaufruf ein; daraus entsteht ein Authorization-Header (Bearer-Token oder HTTP Basic), der auf diesen Nutzer begrenzt ist. Zugangsdaten anderer Nutzer sind hier nie im Spiel.
Schritte 12–13 – Der Aufruf erreicht das angebundene System als dieser Nutzer. Der MCP-Server reicht den Authorization-Header unverändert an das angebundene System weiter. Aus Sicht des angebundenen Systems ist das eine normale API-Anfrage dieses Nutzers. Das angebundene System wendet seine eigenen Zugriffskontrollen an – ACLs, Rollen, Bereiche, Projektmitgliedschaften – genau wie bei jeder anderen Anfrage dieses Nutzers.
Schritte 14–16 – Nur erlaubte Daten kommen zurück. Das angebundene System antwortet mit dem, was dieser Nutzer sehen darf. basebox rahmt das Ergebnis als Daten (nicht als Anweisungen), um Prompt-Injection zu verhindern, und streamt es an den Nutzer zurück.
Zentrale Sicherheitseigenschaften
| Eigenschaft | Umsetzung |
|---|---|
| Isolierung je Nutzer | Die Zugangsdaten jedes Nutzers werden getrennt in settings gespeichert; sie werden zu Beginn jeder Chat-Anfrage anhand der user_id geladen |
| Kein gemeinsames Admin-Token | basebox hält nie ein einzelnes privilegiertes Token, das es für alle Nutzer verwendet; jeder Aufruf wird mit den eigenen Zugangsdaten des anfragenden Nutzers authentifiziert |
| Kein Zugangsdaten-Caching über Nutzer hinweg | Zugangsdaten werden für jede Anfrage frisch aus der Datenbank aufgelöst; sie werden nie über Anfragen hinweg im Prozessspeicher gehalten oder zwischen gleichzeitigen Sitzungen geteilt |
| Das angebundene System setzt seine eigenen Berechtigungen durch | basebox reicht Zugangsdaten durch und gibt zurück, was das System liefert; es fügt keine Filterschicht hinzu und entfernt keine Zugriffsprüfungen |
| Schreibzugriff ist standardmäßig aus | Alle schreibfähigen Werkzeuge (create, update, delete) sind auf KI-App-Ebene standardmäßig deaktiviert; ein Administrator muss sie ausdrücklich aktivieren |
| Vertraulichkeit der Zugangsdaten | Zugangsdaten erscheinen nie in Produktionslogs; sie sind nur auf Log-Level DEBUG und nur im Rahmen gezielter Diagnoseläufe vorhanden |
Was basebox NICHT tut
- Es hält keine eigene Kopie des Berechtigungsmodells des angebundenen Systems.
- Es bildet basebox-Rollen nicht auf Rollen des angebundenen Systems ab.
- Es cacht oder aggregiert keine Antworten über Nutzer hinweg.
- Es gewährt keinen Zugriff über das hinaus, was der Nutzer im angebundenen System bereits hat.
Wird das Konto eines Nutzers im angebundenen System deaktiviert oder sein Token widerrufen, verliert basebox den Zugriff mit der allernächsten Anfrage – es gibt keine Sitzung und keinen Cache, die zu invalidieren wären.
Konfiguration durch Administratoren
Administratoren aktivieren Konnektoren und geben eine Basis-Endpunkt-URL an (und optional ein gemeinsames Nur-Lese-Servicekonto für Konnektoren, die das unterstützen). Jeder einzelne Nutzer gibt dann seine eigenen Zugangsdaten ein, wenn er einen Konnektor in seinem eigenen Profil aktiviert. Der Administrator kann die Zugangsdaten eines anderen Nutzers weder sehen noch verwenden.
Für Konnektoren wie Roxtra, YouTrack oder DokuWiki, die persönliche API-Tokens verwenden, ist der Ablauf:
- Der Administrator aktiviert den Konnektor und setzt die Endpunkt-URL.
- Jeder Nutzer öffnet Einstellungen → Konnektoren, gibt sein persönliches Token ein und klickt auf Verbindung testen.
- Ab diesem Zeitpunkt gehen alle Werkzeugaufrufe dieses Nutzers als dieser Nutzer authentifiziert an das angebundene System.