APIs können eingerichtet werden, um Lese- oder Schreibzugriffe für auf der Lobster Data Platform verwaltete Inhalte zu ermöglichen oder Workflows anzusteuern, die via Integration ggf. auch angebundene Drittsysteme einbeziehen.
Unabhängig vom Verwendungszweck und der Charakteristik einer Schnittstelle (z. B. REST API vs. MCP-Server) sollten Sicherheitsaspekte bei der Konzeption und Umsetzung eine wichtige Rolle spielen.
Die Zugriffkontrolle für Endpunkte einer REST API oder durch einen MCP-Server bereitgestellte Tools kann auf folgenden Ebenen kontrolliert werden:
URL-Zugriff auf die Lobster Data Platform insgesamt
Für wen ist die Platform überhaupt per URL adressierbar?
Aktivierungsstatus der API-Konfiguration (s. API-Manager)
Eine API muss “aktiv” (
enabled) gesetzt sein, sonst sind die Konfigurationen für alle enthaltenen Endpunkte oder Tools kategorisch unwirksam.Falls keine aktive API eine Definition für einen adressierten Endpunkt oder ein Tool enthält, tritt ein HTML-Fehler (
404: Not found) auf.
Authentifizierungspflicht je Endpunkt oder Tool
Für jede Endpunkt- oder Tool-Definition legt das Kennzeichen “Anonymer Zugriff” (
allowAnonymousAccess) fest, ob ein Zugriff ohne Authentifizierung grundsätzlich in Frage kommt (true), oder nicht (false).Ein anonymer Zugriff auf einen Endpunkt, für den das Kennzeichen “Anonymer Zugriff” (
allowAnonymousAccess) nicht gesetzt ist, scheitert mit einem HTML-Fehler (401 Error: Unauthorized) und dem Lobster Data Platform-FehlecodeCORESYSTEM_AuthenticationManager_401im Response Body.
Optional: Zuweisen von Zuordnungskriterien je API und/oder Endpunkt bzw. Tool
Der Zugriff auf eine API oder einen Endpunkt bzw. ein Tool kann durch das Zuweisen von Zuordnungskriterien an die Erfüllung weiterer beliebig komplexer Prüfkriterien gebunden werden.
Die Prüflogik kann sämtliche Regeltypen einziehen.
Für authentifizierte Zugriffe kommt folgenden Regeltypen aus der Kategorie Sitzungsbasiert (Regeln) besondere Bedeutung zu:
Für anonyme Zugriffe ist beim Zuweisen von Zuordnungskriterien zu berücksichtigen, dass diese mangels Sitzungskontext (keine Firma der Session als Bezugspunkt für Besitzereinschränkungen bzw. Firmenfreigaben) nur dann überhaupt als kontextrelevant berücksichtig werden, wenn ihnen kein Besitzer zugeordnet ist. Für vom System vordefinierte Zuordnungskriterien (“An ... zuweisen“) gilt das generell.
Wie bei Zuweisungen üblich gilt: Wenn mehrere Zuordnungskriterien parallel zugewiesen sind, muss mindestens eines erfüllt sein, damit eine Konfiguration als “im Kontext zugeordnet” gilt. Der Zugriff auf REST-API-Endpunkte bzw. MCP-Server-Tools wird also nur aufgrund von Zuweisungen eingeschränkt, wenn ALLE zugewiesenen Zuordnungskriterien ENTWEDER als nicht bestanden gelten ODER aufgrund von Besitzereinschränkungen im Ausführungskontext nicht relevant sind. In jedem dieser Fälle signalisiert der HTML-Fehler im Rückgabewert (
403 Error: Forbidden), dass die Anfrage die API erreicht hat, aber die Bearbeitung verweigert wurde. Der Response body liefert den Lobster Data Platform-FehlercodeCORESYSTEM_AuthenticationManager_403.
Auswahl zwischen konkurrieren Endpunkt/Tool-Definitionen
Es ist technisch nicht ausgeschlossen, dass unterschiedliche API-Konfigurationen Definitionen für dieselbe effektive Endpunkt/Tool-Adresse bereitstellen.
Bei einem Aufruf zur Laufzeit wird eine Reihen von Kriterien hierarchisch geprüft, falls mehrere “Kandidaten” als Adressat in Frage kommen.
Bei einem REST API-Aufruf muss die aufgerufene HTTP-Methode mit der Auswahl in der Endpunkt-Konfiguration übereinstimmen.
Falls “Kandidaten” identifiziert sind, aber keiner davon dieses Kriterium erfüllt, tritt ein HTML-Fehler (
405: Method not allowed) auf. Weitere Kriterien sind dann irrelevant.Falls der Aufruf “anonym” (ohne Anmeldekontext) erfolgt, kommen nur “Kandidaten” in Frage, die “Anonymen Zugriff” zulassen (s. o.: “Authentifizierungspflicht”).
Erfüllen mehrere “Kandidaten” die relevanten Bedingungen, wird die Priorität der übergeordneten API-Konfiguration berücksichtigt (s. API-Manager).
Die Zuweisung von Zuordnungskriterien (je API oder Endpunkt) hat keinen Einfluss auf die Auswahlentscheidung. Solche Kriterien werden erst ausgewertet, nachdem eine Entscheidung getroffen wurde.
Es kann also vorkommen, dass ein “Kandidat” aus einer API mit hoher Priorität, dessen zugewiesene Zuordnungskriterien im Aufrufkontext alle nicht zutreffend sind, einen Aufruf “abfängt” (mit HTML-Fehler
403 Error: Forbidden), für den ein nachrangiger Konkurrent ohne Bindung an Zuordnungskriterien (oder mit einem erfüllten Kriterium) ein im Kontext qualifizierter Adressat gewesen wäre.
WARNUNG Für APIs/Endpunkte/Tools gilt: AUSNAHME KEINE Zuweisung = KEINE Zugriffsbeschränkung
Normalerweise sind Konfigurationen, denen Zuordnungskriterien zugewiesen werden können, operativ unwirksam, solange keine Zuweisung vorliegt.
Dagegen gilt innerhalb einer API-Konfiguration: Solange auf das Zuweisen von Zuordnungskriterien für eine Ebene (API vs. Endpunkt/Tool) komplett verzichtet wird, besteht unbeschränkter Zugriff.
Vor der Einführung der Zugriffskontrolle mit Zuordnungskriterien erstellte API-Konfigurationen bleiben also erreichbar, ohne dass explizite Zuweisungen nötig wären.
Allerdings verhindert das Entfernen aller Zuweisungen im Kontext einer API-Konfiguration ausnahmsweise auch nicht den Zugriff auf betreffende Endpunkte.