APIs ermöglichen Lese- oder Schreibzugriff auf Inhalte der Lobster Data Platform. Sie können APIs auch nutzen, um Workflows anzusteuern. Solche Workflows können über Integration angebundene Drittsysteme einbeziehen.
Sicherheitsaspekte gehören in jede API-Konzeption. Das gilt unabhängig vom Verwendungszweck und der Charakteristik einer Schnittstelle (z. B. REST API oder MCP-Server).
Die Zugriffskontrolle für Endpunkte einer REST API oder für Tools eines MCP-Server arbeitet auf 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 ist die URL-Erreichbarkeit der Lobster Data Platform. Klären Sie zuerst eine Frage: Für wen ist die Plattform überhaupt per URL adressierbar?
Aktivierungsstatus der API-Konfiguration
Eine API muss aktiv (enabled) gesetzt sein. Sonst sind alle enthaltenen Endpunkt- und Tool-Konfigurationen kategorisch unwirksam.
Existiert keine aktive API mit einer passenden Definition für den adressierten Endpunkt oder das Tool, antwortet die Plattform mit 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 trägt das Kennzeichen Anonymer Zugriff (Code-Bezeichner: allowAnonymousAccess). Dieses Kennzeichen entscheidet, ob ein Zugriff ohne Authentifizierung möglich ist:
true: anonymer Zugriff erlaubtfalse: nur authentifizierter Zugriff
Schlägt ein anonymer Zugriff am Kennzeichen Anonymer Zugriff fehl, antwortet die Plattform mit HTTP-Fehler 401 Error: Unauthorized. Der response body liefert dann den Lobster Data Platform-Fehlercode CORESYSTEM_AuthenticationManager_401.
Optional: Zuweisen von Zuordnungskriterien
Sie können den Zugriff auf eine API, einen Endpunkt oder ein Tool zusätzlich an Zuordnungskriterien binden. Damit lassen sich beliebig komplexe Prüfkriterien definieren.
Die Prüflogik kann sämtliche Regeltypen auswerten.
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 als kontextrelevant, wenn ihnen kein Besitzer zugeordnet ist. Für vom System vordefinierte Zuordnungskriterien („An … zuweisen“) gilt das generell.
Vorrang von Endpunkt- und API-Ebene
Zuordnungskriterien lassen sich auf zwei Ebenen zuweisen. Die erste Ebene ist die API. Die zweite Ebene ist der einzelne Endpunkt oder das einzelne Tool.
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.
Nur ohne Zuordnungskriterien auf Endpunkt- oder Tool-Ebene greift 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 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.
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 als Adressat 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 HTTP-Fehler 405: Method not allowed. Weitere Kriterien werden dann nicht mehr geprüft.
Schritt 2: Anonymer Aufruf
Erfolgt der Aufruf anonym (ohne Sitzungskontext), kommen nur Kandidaten infrage, die anonymen Zugriff zulassen. Siehe dazu 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. Das geschieht auch dann, wenn seine zugewiesenen Zuordnungskriterien im Aufrufkontext nicht zutreffen. Die Plattform liefert dann den HTTP-Fehler 403 Error: Forbidden. Ein nachrangiger Konkurrent ohne Zuordnungskriterien wäre eigentlich qualifiziert gewesen.
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 sind in der Regel operativ unwirksam, 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.