APIs ermöglichen Lese- oder Schreibzugriff auf Inhalte der Lobster Data Platform. Sie können APIs auch nutzen, um Workflows anzusteuern. Solche Workflows binden oft Drittsysteme über eine Integration ein.
Sicherheit gehört in jede API-Planung. Das gilt für jeden Einsatzzweck und jede Schnittstellenart, zum Beispiel für REST API und MCP-Server.
Die Zugriffskontrolle für Endpunkte einer REST API oder für Tools eines MCP-Server prüft vier Ebenen:
URL-Zugriff auf die Plattform
Aktivierungsstatus der API-Konfiguration
Authentifizierungspflicht je Endpunkt oder Tool
Optional: Zuweisen von Zuordnungskriterien
URL-Zugriff auf die Plattform
Die erste Kontrollebene prüft, ob die Lobster Data Platform per URL erreichbar ist. Klären Sie zuerst: Wer kann die Plattform überhaupt per URL erreichen?
Aktivierungsstatus der API-Konfiguration
Eine API muss aktiv sein (enabled). Ist sie es nicht, funktioniert keine der enthaltenen Endpunkt- oder Tool-Konfigurationen.
Gibt es keine aktive API mit passender Definition für den Endpunkt oder das Tool, antwortet die Plattform mit dem HTTP-Fehler 404: Not found.
Details zum Aktivieren einer API-Konfiguration finden Sie unter API-Manager.
Authentifizierungspflicht je Endpunkt oder Tool
Jede Endpunkt- oder Tool-Definition hat das Kennzeichen Anonymer Zugriff. Es legt fest, ob ein Zugriff ohne Authentifizierung möglich ist:
true: anonymer Zugriff erlaubtfalse: nur authentifizierter Zugriff
Im Code trägt dieses Kennzeichen den Namen allowAnonymousAccess. Die Bezeichnung in der Benutzeroberfläche und der Code-Name meinen dasselbe Feld.
Ist das Kennzeichen Anonymer Zugriff auf false gesetzt und der Zugriff erfolgt trotzdem anonym, antwortet die Plattform mit dem HTTP-Fehler 401 Error: Unauthorized. Der response body enthält dann den Lobster Data Platform-Fehlercode CORESYSTEM_AuthenticationManager_401.
Sicherheitsrisiko bei anonymem Zugriff
Prüfen Sie vor jeder Freigabe für anonymen Zugriff genau, wie sicher die hinterlegte Aktion ist.
ACHTUNG: Anonyme Aufrufe haben keinen Sitzungskontext.
Ein Workaround über Ausführen als kann das kompensieren. Nutzt die hinterlegte Aktion dabei eine Rolle ohne Besitzereinschränkung, zum Beispiel Superuser, kann der anonyme Endpunkt sensible Daten ungeschützt preisgeben.
Testen Sie anonymen Zugriff nie in einem Browser-Fenster, in dem bereits eine Sitzung an der Lobster Data Platform angemeldet ist. Das Sitzungs-Cookie greift dort automatisch und verfälscht den Test. Nutzen Sie stattdessen ein privates Fenster oder einen separaten REST-Client.
Optional: Zuweisen von Zuordnungskriterien
Sie können den Zugriff auf eine API, einen Endpunkt oder ein Tool zusätzlich an Zuordnungskriterien binden. Damit definieren Sie beliebig komplexe Prüfkriterien.
Die Prüflogik wertet sämtliche Regeltypen aus.
Regeltypen für authentifizierte Zugriffe
Für authentifizierte Zugriffe spielen folgende Regeltypen aus der Kategorie Sitzungsbasiert (Regeln) eine besondere Rolle:
Besonderheit bei anonymen Zugriffen
Anonymen Zugriffen fehlt ein Sitzungskontext. Es gibt keinen Firma der Session als Bezugspunkt. Damit fehlt auch eine Basis für Besitzereinschränkungen oder Firmenfreigaben.
Daraus folgt: Zuordnungskriterien gelten für anonyme Zugriffe nur dann, wenn ihnen kein Besitzer zugeordnet ist. Für vom System vordefinierte Zuordnungskriterien („An … zuweisen") gilt das immer.
Vorrang von Endpunkt- und API-Ebene
Sie können Zuordnungskriterien auf zwei Ebenen zuweisen: auf der API-Ebene oder auf der Ebene des einzelnen Endpunkts oder Tools.
Die Plattform prüft pro Aufruf nur eine Ebene. Hat ein Endpunkt oder ein Tool eigene Zuordnungskriterien, prüft die Plattform nur diese. Die Kriterien der API-Ebene bleiben dann unberücksichtigt.
Ohne Zuordnungskriterien auf Endpunkt- oder Tool-Ebene greift stattdessen die API-Ebene.
Verhalten bei mehreren zugewiesenen Kriterien
Sind mehrere Zuordnungskriterien parallel zugewiesen, muss mindestens eines erfüllt sein. Nur dann gilt die Konfiguration als „im Kontext zugeordnet".
Der Zugriff auf REST-API-Endpunkte oder MCP-Server-Tools wird durch Zuweisungen also nur dann eingeschränkt, wenn alle zugewiesenen Kriterien einen der folgenden Status haben:
Nicht bestanden: Das Kriterium ist im Aufrufkontext fehlgeschlagen.
Nicht relevant: Besitzereinschränkungen im Aufrufkontext schließen das Kriterium aus.
In beiden Fällen antwortet die Plattform mit dem HTTP-Fehler 403 Error: Forbidden. Die Anfrage hat die API erreicht, die Bearbeitung wurde aber verweigert. Der response body liefert den Lobster Data Platform-Fehlercode CORESYSTEM_AuthenticationManager_403.
Die Fehlermeldung zu diesem Code lautet „Ungültige Anmeldedaten". Dies ist ungenau. Der Fehler tritt auch bei einem gültigen, sogar anonymen Aufruf auf, wenn die zugewiesenen Zuordnungskriterien nicht zutreffen. Er bedeutet nicht zwingend, dass Zugangsdaten falsch sind.
Auswahl zwischen konkurrierenden Endpunkt-/Tool-Definitionen
Technisch können verschiedene API-Konfigurationen Definitionen für dieselbe effektive Endpunkt- oder Tool-Adresse bereitstellen. Kommen zur Laufzeit mehrere Kandidaten infrage, prüft die Plattform sie hierarchisch.
Schritt 1: Übereinstimmung der HTTP-Methode
Bei einem REST API-Aufruf muss die HTTP-Methode mit der Endpunkt-Konfiguration übereinstimmen.
Erfüllt keiner der Kandidaten dieses Kriterium, antwortet die Plattform mit dem HTTP-Fehler 405: Method not allowed. Weitere Kriterien prüft die Plattform dann nicht mehr.
Schritt 2: Anonymer Aufruf
Erfolgt der Aufruf anonym, also ohne Sitzungskontext, kommen nur Kandidaten infrage, die anonymen Zugriff zulassen. Siehe dazu weiter oben den Abschnitt Authentifizierungspflicht je Endpunkt oder Tool.
Schritt 3: Priorität der API-Konfiguration
Erfüllen mehrere Kandidaten die relevanten Bedingungen, entscheidet die Priorität der übergeordneten API-Konfiguration. Details finden Sie unter API-Manager.
Schritt 4: Zuordnungskriterien werden später ausgewertet
Die Zuweisung von Zuordnungskriterien beeinflusst die Auswahl nicht. Die Plattform wertet Zuordnungskriterien erst aus, nachdem sie sich für einen Kandidaten entschieden hat.
Das Verhalten ist dadurch nicht offensichtlich. Ein Kandidat aus einer API mit hoher Priorität kann einen Aufruf abfangen, selbst wenn seine zugewiesenen Zuordnungskriterien im Aufrufkontext nicht zutreffen. Die Plattform liefert dann den HTTP-Fehler 403 Error: Forbidden. Ein nachrangiger Konkurrent ohne Zuordnungskriterien hätte die Anfrage sonst bedienen können.
Sonderfall: Keine Zuweisung = keine Zugriffsbeschränkung
WARNUNG: Für APIs, Endpunkte und Tools gilt: keine Zuweisung = keine Zugriffsbeschränkung.
Manche Konfigurationen lassen die Zuweisung von Zuordnungskriterien zu. Solche Konfigurationen wirken in der Regel nicht, solange keine Zuweisung vorliegt.
Für API-Konfigurationen gilt das Gegenteil. Eine Ebene ohne zugewiesene Zuordnungskriterien gewährt unbeschränkten Zugriff. Das gilt für die API-Ebene und für die Endpunkt- oder Tool-Ebene.
Daraus folgen zwei Konsequenzen:
API-Konfigurationen, die vor der Einführung der Zugriffskontrolle entstanden sind, bleiben ohne explizite Zuweisungen erreichbar.
Das Entfernen aller Zuweisungen auf API-Ebene hebt den Schutz nur für Endpunkte ohne eigene Zuordnungskriterien auf. Endpunkte mit eigenen Zuordnungskriterien bleiben geschützt.