Zum Hauptinhalt springen
Daten nutzen · Eigene Anwendung

Eigene Anwendung integrieren

Nutzen Sie die Daten-, Identitäts- und API-Bausteine der UDSP für eine eigene Fachanwendung. Die Anwendung erhält einen klar abgegrenzten Datenzugang, verwendet Keycloak für die Anmeldung und wird kontrolliert in die Plattform eingebunden.

Eine eigene Anwendung ist sinnvoll, wenn Dashboard, Kartenanwendung oder Datenkatalog den fachlichen Arbeitsablauf nicht ausreichend abbilden – beispielsweise weil Nutzer Datensätze bearbeiten, mehrere Plattform-APIs in einem Vorgang verbinden oder eine spezifische Benutzerführung benötigen.

Vorhandenes Werkzeug oder eigene Anwendung?

Verwenden Sie Grafana oder Superset für Dashboards, Masterportal für vorhandene Kartenthemen und CKAN für Datenangebote. Eine eigene Anwendung lohnt sich erst, wenn ein konkreter Arbeitsablauf darüber hinausgeht. Sie bringt einen eigenen Entwicklungs-, Sicherheits-, Betriebs- und Pflegeaufwand mit.

Der Weg in die Plattform​

1 · Bedarf

Arbeitsablauf festlegen

Benennen, was Nutzer sehen oder tun sollen und warum vorhandene Werkzeuge dafür nicht ausreichen.

2 · Daten

Schnittstellen auswählen

Nur die benötigten veröffentlichten Fach-APIs und erlaubten Operationen festlegen.

3 · Zugriff

Anmeldung und Rechte planen

Keycloak-Client, Benutzer- oder Dienstzugriff sowie benötigte Rollen und Scopes abstimmen.

4 · Einbindung

Anwendung bereitstellen

Domain, TLS, Gatewayzugang, HYPERSENSUS-Einstieg und technischen Betrieb gemeinsam abnehmen.

Plattformbausteine gezielt verwenden​

Fachdaten

Veröffentlichte Datenzugänge

Stellio über NGSI-LD, FROST über SensorThings, GeoServer über OGC oder weitere ausdrücklich freigegebene APIs verwenden.

Identität

Keycloak-Anmeldung

Benutzer und technische Clients im Mandanten-Realm authentifizieren und nur benötigte Rollen beziehungsweise Scopes anfordern.

Gateway

APISIX-Zugang

Geschützte Fach-APIs über stabile HTTPS-Pfade verwenden; interne Kubernetes-Dienste bleiben verborgen.

Plattformzugang

HYPERSENSUS-Einstieg

Die bereitgestellte Anwendung als sichtbaren Dienst für die vorgesehene Zielgruppe auffindbar machen.

Greifen Sie nicht direkt auf interne Datenbanken oder wechselnde Kubernetes-Serviceadressen zu. Verwenden Sie die veröffentlichte Schnittstelle, die zum Datenmodell gehört. Dadurch bleiben Zugriffsschutz, Mandantenkontext und spätere technische Änderungen an einer klaren Plattformgrenze gebündelt.

Datenzugang der Anwendung festlegen​

Wählen Sie den Datenzugang nach dem fachlichen Modell und nicht nach dem Framework der Anwendung:

  • NGSI-LD über Stellio, wenn aktuelle fachliche Objekte mit Eigenschaften und Beziehungen benötigt werden;
  • SensorThings über FROST, wenn die Anwendung Sensoren, Datastreams und einzelne Beobachtungen verwendet;
  • OGC-Dienste über GeoServer, wenn freigegebene Geodaten als Karten- oder Objektservice genutzt werden;
  • CKAN Action API, wenn katalogisierte Datenangebote gesucht oder Metadaten verarbeitet werden.

Dokumentieren Sie für jeden Aufruf Basis-URL, Ressource, benötigte HTTP-Methoden, fachlichen Datenraum, erwartete Antwort, Fehlerstatus und benötigte Berechtigung. Die veröffentlichten Wege sind unter Schnittstellen der UDSP beschrieben.

APISIX ist nicht der Datenbestand

APISIX schützt und routet einen veröffentlichten API-Pfad. Datenmodell, fachliche Prüfung und Speicherung bleiben bei Stellio, FROST, GeoServer oder einem anderen Zielsystem. Eine neue Route ersetzt daher weder die Fach-API noch deren Berechtigungskonzept.

Anmeldungsweg auswählen​

Eine Browseranwendung meldet den Benutzer über einen eigenen Keycloak-Client an. Verwenden Sie einen für öffentliche Clients geeigneten OIDC-Ablauf mit Authorization Code und PKCE. Redirect-URIs und Web Origins werden auf die tatsächlichen Anwendungsadressen begrenzt.

Ein Client-Secret gehört niemals in JavaScript, Browser-Storage oder ein ausgeliefertes Frontend-Bundle. Die Anwendung sendet das kurzlebige Access Token nur an den vorgesehenen geschützten API-Pfad und zeigt Funktionen entsprechend der fachlich benötigten Rechte an. Die API muss die Berechtigung trotzdem selbst durchsetzen.

Die technische Ausgestaltung des Clients richtet sich nach dem freigegebenen Zugriffsmodell. Die Plattformgrundlagen stehen unter Authentifizierung und API-Zugriff, Keycloak und APISIX.

Übergabe für die Bereitstellung vorbereiten​

Stellen Sie der Administration und dem Plattformbetrieb einen kleinen, prüfbaren Anwendungssteckbrief bereit:

Beispiel für einen Anwendungssteckbrief
Anwendung:           Verkehrsübersicht
Nutzeraufgabe:       aktuelle Zählwerte je Messstelle prüfen und kommentieren
Öffentliche URL:     https://verkehr.<DOMAIN>
Datenzugang:         GET über die freigegebene NGSI-LD-Route
Datenraum:           vereinbarter fachlicher Datenraum
Anmeldung:           Benutzeranmeldung über eigenen Keycloak-Client
Benötigte Rechte:    nur lesender API-Zugriff; keine Löschoperation
HYPERSENSUS:         Service-Karte für die freigegebene Zielgruppe
Betriebsnachweis:    Health-Endpunkt, Logs ohne Tokens, zuständige Kontaktstelle

Auf dieser Grundlage werden mindestens folgende Punkte abgestimmt:

  1. Container-Image, Version und reproduzierbarer Bereitstellungsweg;
  2. stabile Domain, TLS und gegebenenfalls Ingress beziehungsweise APISIX-Route;
  3. Keycloak-Client, Redirect-URIs, Rollen und technische Identitäten;
  4. erlaubte Datenräume, APIs, Methoden und CORS-Regeln;
  5. Secret-Bereitstellung, Protokollierung, Monitoring und Aktualisierung;
  6. sichtbarer Einstieg in HYPERSENSUS und Test mit einem vorgesehenen Benutzerzugang.
Technische Einbindung ist eine gemeinsame Aufgabe

Benutzer und Entwicklung beschreiben Arbeitsablauf, Datenbedarf und Anwendung. Administration beziehungsweise Plattformbetrieb stellen Identität, Rollen, Routen, Laufzeit und sichtbaren Einstieg kontrolliert bereit. Legen Sie keine produktiven Keycloak-Clients, APISIX-Routen oder Clusterressourcen außerhalb dieses Weges an.

Anwendung abnehmen​

  • Anmeldung und Abmeldung funktionieren mit einem Zugang der vorgesehenen Zielgruppe.
  • Die Anwendung erreicht nur die freigegebenen APIs, Datenräume und HTTP-Methoden.
  • Fehlende oder abgelaufene Rechte führen zu einem verständlichen Fehler und nicht zu einem ungeschützten Ersatzweg.
  • Angezeigte Werte lassen sich am veröffentlichten Datenzugang nachvollziehen.
  • Tokens, Secrets und schützenswerte Payloads erscheinen nicht in URL, Browserprotokoll oder Anwendungslogs.
  • Die Anwendung ist über ihre vorgesehene URL und – falls vereinbart – über HYPERSENSUS erreichbar.
  • Version, Betriebskontakt, Aktualisierungsweg und bekannte Grenzen sind dokumentiert.

Referenzen​