Datenprodukt-Portal-Integrationen 1: OIDC
19.07.2024
•
Stijn Janssens
Wie man Open ID Connect mit dem Data Product Portal integriert
Hallo zusammen! Ich freue mich, diese neue Blogbeitragsreihe der Welt vorzustellen. Ich hoffe, viele weitere Beiträge teilen zu können und lade euch alle ein, mich auf diesen Abenteuern zu begleiten.
Was ist das Data Product Portal?
Das Data Product Portal ist ein Open-Source-Tool, das Organisationen dabei hilft, Datenprodukte in großer Anzahl zu erstellen und zu verwalten. Es ist intuitiv, flexibel und darauf ausgelegt, das Management von Datenprodukten einfach und effektiv zu gestalten.
Für weitere Informationen, schaut euch unseren Ankündigungsblogbeitrag an. Er behandelt das „Warum, Was und Wie“ des Data Product Portals und führt in wichtige Konzepte ein. Im Verlauf dieser Reihe werde ich das Data Product Portal als „das Portal“ bezeichnen.
Das Portal ist Open-Source! Besucht unser Github und hinterlasst einen Stern, wenn euch gefällt, was ihr seht. Ihr könnt auch unserer Slack-Community beitreten, um direkt mit uns zu plaudern.
Was ist diese Blogbeitragsreihe?
Das Portal ist für eine einfache Einrichtung konzipiert. Führt einfach docker compose up
oder helm install
auf eurem K8S-Cluster aus, und ihr seid bereit. Das wird euch eine minimalistische Version des Portals präsentieren. Die Funktionen des Portals werden jedoch wirklich spannend, wenn sie mit anderen Diensten integriert werden, wie beispielsweise AWS für das Rollenmanagement oder OIDC für die Benutzerauthentifizierung.
Diese Blogreihe wird euch durch verschiedene Integrationen für das Portal mit technischen Beispielen führen. Themen sind die Integration des Portals mit OIDC, die Verknüpfung des Portals mit AWS und die Anbindung an Conveyor.
Die Verfolgung dieser Serie wird euch helfen, das Portal vollständig zu nutzen, indem ihr es mit wesentlichen Technologien integriert und ein umfassendes Zentrum für eure Datenprofis schafft.
Dieser Blogbeitrag konzentriert sich auf die Integration mit OIDC.
Warum benötigt ihr die OIDC-Integration?
Das Portal ermöglicht den großflächigen Datenzugriff innerhalb eurer Organisation. Ein wichtiges Merkmal ist die Fähigkeit, Benutzer zu authentifizieren und zu autorisieren. Durch die Überprüfung der Benutzeridentitäten kann das Portal sicher und korrekt den Zugriff auf die entsprechenden Datenprodukte gewähren.
Ohne OIDC erscheinen alle Benutzer als „John Doe“, was es unmöglich macht, die Zugriffsrechte zu unterscheiden. Die Aktivierung von OIDC ist der erste Schritt, um eure Portal-Installation für die gesamte Organisation nützlicher zu machen.
Was ist OIDC?
OpenID Connect (OIDC) ist ein Identitätsauthentifizierungsprotokoll, das eine Erweiterung der offenen Autorisierung (OAuth) 2.0 darstellt, um den Prozess der Authentifizierung und Autorisierung von Benutzern beim Anmelden für den Zugriff auf digitale Dienste zu standardisieren.
Wenn ihr OIDC mit dem Portal implementiert, könnt ihr das Portal mit dem SSO oder Identitätsanbieter eurer Organisation verknüpfen, was eine sichere Benutzeranmeldung und benutzerspezifischen Datenzugriff ermöglicht.


So integriert ihr OIDC mit dem Portal
Unterstützte Anbieter
Das Portal wurde mit AWS Cognito getestet, sollte aber auch mit anderen OIDC-Anbietern mit minimalen Codeänderungen funktionieren. Als Open-Source-Projekt sind Beiträge zur Unterstützung zusätzlicher OIDC-Anbieter willkommen.
OIDC gibt identity
, refresh
und access
-Tokens zurück. Die Anbieter können sich in den Informationen unterscheiden, die sie in den Tokens übermitteln, und die Anwendung hängt von diesen Informationen ab, sodass die Integration eines neuen Anbieters möglicherweise auch einige Änderungen im Code erfordert.
Die Ansprüche, die unser Anbieter übermitteln muss, sind mindestens email
, family_name
und name
.
Cognito-Setup
Ich werde das vollständige Setup eines Cognito-Benutzerpools nicht behandeln (das könnt ihr hier finden), hier sind die wichtigen Punkte für das Portal:
Fügt
email
,family_name
undname
zu denrequired_attributes
in eurem Benutzerpool hinzu.Erstellt eine App-Integration und notiert die Client-ID und das Geheimnis.
Findet die Autoritäts-URL mit folgendem Format:
Stellt die korrekten Callback-URLs ein.
Ich werde diese Schritte im Folgenden genauer erläutern.
Portal verwendet Cognito User Pools. Stellt sicher, dass ihr beim Erstellen eures Benutzerpools mindestens email
, family_name
und name
zu den required_attributes
hinzufügt. Diese Ansprüche werden im Portal verwendet.
Euer Benutzerpool benötigt genau eine App-Integration.

Wenn ihr auf diese App-Integration klickt, könnt ihr die Client-ID und das Geheimnis eures App-Clients herausfinden. Diese Werte sind unten wichtig.

Der letzte Wert, den ihr finden müsst, ist die Autoritäts-URL. Im Falle von Cognito könnt ihr sie mit der folgenden Vorlage erstellen.
Für andere OIDC-Anbieter benötigen wir die URL, die die Datei .well-known/openid-configuration
eures Anbieters hostet.
Callback-URLs
Das Portal benötigt bestimmte Callback-URLs, die von Cognito erlaubt sind. Diese sind für die lokale Entwicklung und die Produktion erforderlich. Stellt sicher, dass die folgenden URLs in eurer Liste der erlaubten Abmelde-Callback-URLs enthalten sind:
Für die lokale Entwicklung:
Für die Produktion (HOST ist der CNAME eurer Anwendung — der DNS-Eintrag, der den Aliasnamen eurer Anwendung mit ihrem tatsächlichen oder kanonischen Domainnamen verknüpft):
Die folgende Liste muss der Liste der erlaubten Abmelde-Callback-URLs hinzugefügt werden.
OIDC lokal integrieren / Docker-Integration
Backend
Beim Ausführen des Portals lokal erfolgt die meiste Integration externer Dienste in einer .env
-Konfigurationsdatei.
Das Ausführen von docker compose up
verwendet standardmäßig .env.docker
. Wenn ihr eure Docker-Container lokal für die Bereitstellung erstellen möchtet, müsst ihr eine .env
-Datei im Stammverzeichnis des Projekts erstellen. Bitte verweist auf die README in backend/
für weitere Erklärungen.
Stellt sicher, dass die folgenden Konfigurationswerte in der .env
-Datei enthalten sind, die in eurer Docker-Bereitstellungspipeline verwendet wird. Die Werte können aus eurem Cognito-Benutzerpool abgeleitet werden, wie oben erklärt.
Frontend
Der Frontend-Docker, der beim lokalen Ausführen oder beim Ausführen von npm dev
verwendet wird, nutzt eine config.js
-Datei. Bitte verweist auf die README in frontend/
für weitere Erklärungen, wie ihr dies einrichten könnt. Die Datei sollte den folgenden Code enthalten:
OIDC in eurer Produktionsinstallation integrieren
Der einfachste Weg, das Portal in einer Produktionsumgebung bereitzustellen, erfolgt über Helm. Ihr könnt OIDC in Helm aktivieren, indem ihr die folgende Konfiguration in der values.yaml
-Datei, die über Helm bereitgestellt wird, übermittelt.
Stellt sicher, dass eure values.yaml
die folgenden Einträge enthält.
Fazit
Das Einrichten der OIDC-Unterstützung für eure Portal-Bereitstellung ist unkompliziert. Passt die .env
- und config.local.js
-Dateien für die lokale Entwicklung an oder übermittelt Werte in values.yaml
für Helm-Installationen.
Lasst mich wissen, ob dieses Tutorial klar war, und zögert nicht, Fragen zu stellen. Schließt euch uns auf Github oder in unserer Slack-Community an. Bleibt dran für die nächste Folge dieser Reihe!
Latest
Portable by design: Rethinking data platforms in the age of digital sovereignty
Build a portable, EU-compliant data platform and avoid vendor lock-in—discover our cloud-neutral stack in this deep-dive blog.
Cloud-Unabhängigkeit: Test eines europäischen Cloud-Anbieters gegen die Giganten
Kann ein europäischer Cloud-Anbieter wie Ionos AWS oder Azure ersetzen? Wir testen es – und finden überraschende Vorteile in Bezug auf Kosten, Kontrolle und Unabhängigkeit.
Vermeide schlechte Daten von Anfang an
Das Erfassen aller Daten ohne Qualitätsprüfungen führt zu wiederkehrenden Problemen. Priorisieren Sie die Datenqualität von Anfang an, um nachgelagerte Probleme zu vermeiden.