Administration · Datenzugänge

Datenraum bereitstellen

Ein neuer Datenraum verbindet einen stabilen technischen Namen, einen registrierten Stellio-Tenant und die passende Zugriffszuordnung. Diese Anleitung zeigt, welche Angaben benötigt werden, wo Plattformbetrieb und Administration zusammenarbeiten und wie der fertige Zugang geprüft wird.

Ein Datenraum wie ds_environment ist nicht einfach ein frei angelegtes PostgreSQL-Schema. In Stellio bezeichnet er einen isolierten NGSI-LD-Tenant. Stellio ordnet diesem Tenant intern ein eigenes Datenbankschema zu; APISIX und Keycloak stellen sicher, dass nur berechtigte Identitäten den Namen im Header NGSILD-Tenant verwenden können.

Name

Datenraum festlegen

Fachlicher Zweck und stabiler technischer Name sind eindeutig.

→

Stellio

Tenant registrieren

Der Plattformbetrieb ergänzt die Tenant-Konfiguration und startet Stellio kontrolliert neu.

→

Zugriff

Berechtigung zuordnen

Benutzer oder technischer Zugang erhalten Datenraum und benötigte API-Rechte.

→

Abnahme

API-Zugang prüfen

Token-Claim, erlaubter Abruf und gesperrter Gegenversuch werden nachgewiesen.

Was dabei tatsächlich entsteht

Öffentlicher Bezeichner

Datenraumname

Der stabile Name, beispielsweise ds_environment, wird in API-Aufrufen und Zugriffszuordnungen verwendet.

Kontextverwaltung

Stellio-Tenant

Der registrierte Tenant trennt Entitäten, Abfragen und Subscriptions von anderen Datenräumen.

Interne Persistenz

Stellio-Schema

Stellio erzeugt und migriert das zugeordnete PostgreSQL-Schema beim kontrollierten Neustart selbst.

Zugriffsschutz

Token-Zuordnung

Der Datenraum muss im tenants-Claim der aufrufenden Identität stehen; API-Scopes bestimmen zusätzlich die erlaubte Operation.

Legen Sie ds_environment nicht manuell in stellio_search oder stellio_subscription an. Stellio führt für jeden registrierten Tenant eigene Migrationen aus und erzeugt das Schema beim Neustart. Ein manuell angelegtes, unvollständiges Schema kann den Start oder spätere Updates verhindern.

1. Zweck und technischen Namen festlegen

Prüfen Sie zuerst, ob ein neuer Datenraum fachlich und technisch benötigt wird. Die Best Practice Datenräume sinnvoll aufbauen erklärt Zuschnitt und Abgrenzung. Ein neuer Datenraum ist sinnvoll, wenn Datenbestände gemeinsam geschützt, aber von anderen fachlichen Bereichen getrennt werden sollen.

Verwenden Sie für den technischen Namen eine dauerhaft stabile, datenbanktaugliche Schreibweise. Für neue UDSP-Datenräume ist ein Name nach dem Muster ds_<bereich> sinnvoll, beispielsweise:

Fachlicher Name: Umweltdaten
Technischer Name: ds_environment
Verwendung: NGSI-LD-Entitäten zu Umweltmessungen
Benötigter Zugriff: lesend für Fachanwendungen, schreibend für den Integrationsflow

Ändern Sie den technischen Namen später nicht beiläufig. Er wird Bestandteil von Tenant-Konfiguration, Datenbankschema, Token-Claim, Integrationsflows und API-Aufrufen.

2. Stellio-Tenant durch den Plattformbetrieb registrieren lassen

Stellio unterstützt keine spontane Erstellung eines produktiven Tenants über die NGSI-LD-API. Der Plattformbetrieb muss den Tenant mit Name, Identity-Provider-Zuordnung und Datenbankschema in der Stellio-Konfiguration ergänzen und anschließend Search- und Subscription-Service kontrolliert neu starten. Erst dabei erzeugt Stellio das zugehörige Schema.

Übergeben Sie dafür mindestens:

Angabe	Beispiel	Bedeutung
fachlicher Zweck	Umweltdaten	grenzt den Inhalt gegenüber vorhandenen Datenräumen ab
externer Datenraumname	ds_environment	Wert für NGSILD-Tenant und Zugriffszuordnung
internes Datenbankschema	ds_environment	von Stellio verwaltete technische Trennung
Identity Provider	Realm des bereitgestellten Mandanten	Quelle der Identitäten und Token
benötigte Operationen	Lesen und Schreiben	Grundlage für die zusätzlich benötigten API-Rechte

Plattformänderung mit Administrationsanteil

Die Tenant-Registrierung und der Stellio-Neustart gehören zum Plattformbetrieb. Die fachliche Benennung, Zugriffszuordnung und Abnahme gehören zur Mandantenadministration. Diese Seite verbindet beide Teile, ersetzt aber keinen kontrollierten Deployment- und Änderungsprozess.

3. Datenraum und API-Rechte zuordnen

Nach der technischen Bereitstellung benötigt jede aufrufende Identität zwei voneinander getrennte Freigaben:

1. Datenraumzuordnung: Der Access Token enthält im Claim tenants einen Eintrag mit dem Namen ds_environment.
2. Aktionsrecht: Der Token enthält den für den Aufruf benötigten Scope, beispielsweise api:read oder api:write.

In der Benutzerverwaltung von HYPERSENSUS kann die Aktion Dataspaces vorhandene Datenräume einem Benutzer zuordnen, sofern diese Funktion für den eingesetzten Stand freigeschaltet ist. Sie erstellt jedoch keinen neuen Stellio-Tenant. Fehlt der Datenraum in der Auswahl, ist zuerst die technische Bereitstellung beziehungsweise die Keycloak-Konfiguration zu klären.

Im Keycloak-basierten Zugriffsweg der UDSP wird der Datenraum durch eine entsprechend gekennzeichnete Datenraumgruppe in den tenants-Claim übernommen. Verwenden Sie für die Zuordnung den freigegebenen Administrationsweg des eingesetzten Releases und prüfen Sie anschließend einen neu ausgestellten Access Token. Eine bereits bestehende Sitzung enthält die neue Zuordnung noch nicht.

Die eigentliche Vergabe ist unter Rollen und Rechte verwalten beschrieben. Technische Integrationsflows benötigen eine eigene technische Identität; verwenden Sie dafür kein persönliches Benutzerkonto.

4. Datenraum über die veröffentlichte API abnehmen

Fordern Sie mit der vorgesehenen Testidentität einen neuen Access Token an. Prüfen Sie im decodierten Payload, dass der Datenraum enthalten ist, ohne den Token in Tickets oder Screenshots zu veröffentlichen:

{
  "tenants": [
    {"name": "ds_environment"}
  ],
  "scope": "openid api:read"
}

Fragen Sie anschließend eine kleine, ungefährliche Ergebnismenge über den veröffentlichten APISIX-Pfad ab:

curl --fail --show-error --get \
  "https://api.<DOMAIN>/stellio/api/ngsi-ld/v1/entities" \
  --header "Authorization: Bearer $ACCESS_TOKEN" \
  --header "NGSILD-Tenant: ds_environment" \
  --header "Accept: application/ld+json" \
  --data-urlencode "limit=1"

Ein leerer Datenraum darf mit 200 OK und einer leeren Ergebnisliste antworten. Das beweist, dass Route, Tenant-Registrierung und Lesezugriff funktionieren; es beweist noch nicht, dass bereits Fachdaten integriert wurden.

Prüfen Sie zusätzlich mit einer Identität ohne Datenraumzuordnung, dass derselbe Aufruf abgewiesen wird. Ein erfolgreicher Test mit einer Plattform- oder Volladministrationsidentität ist kein ausreichender Nachweis für normale Benutzer oder technische Flows.

Was der Datenraum nicht automatisch bereitstellt

• Ein Stellio-Datenraum erzeugt keinen MinIO-Bucket und keine frei verwendbare PostgreSQL-Fachdatenbank.
• GeoServer-Workspaces, Superset-Datasets und Grafana-Datenquellen werden separat eingerichtet.
• Eine Stellio-Historisierung benötigt zusätzlich eine Subscription und den vorgesehenen Historisierungsweg.
• Datenmodelle, JSON-LD-Kontexte und Entity-IDs müssen weiterhin für den Datenfluss festgelegt werden.

Die internen Stellio-Schemata sind keine alternative Benutzerschnittstelle. Schreiben und prüfen Sie Kontextdaten über die geschützte NGSI-LD-API.

Referenzen