Datenprodukt-Portal-Integrationen 1: OIDC

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 benutzer­spezifischen 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 und name zu den required_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:

https://cognito-idp.<COGNITO_REGION>.amazonaws.com/<COGNITO_USER_POOL_ID>

• 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.

https://cognito-idp.<COGNITO_REGION>.amazonaws.com/<COGNITO_USER_POOL_ID>

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):

https://<HOST>/https://<HOST>/api/auth/device/callback/https://<HOST>

Die folgende Liste muss der Liste der erlaubten Abmelde-Callback-URLs hinzugefügt werden.

http://localhost:3000/logout/ # For local developmenthttps://<HOST>

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.

OIDC_CLIENT_ID=<ID> # Cognito Client IDOIDC_CLIENT_SECRET=<SECRET> # Cognito client secretOIDC_AUTHORITY=<AUTH_URL>

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:

const config = (() => {    return {        API_BASE_URL: "http://localhost:5050",        OIDC_DISABLED: false,        OIDC_CLIENT_ID: "<CLIENT_ID>",        OIDC_CLIENT_SECRET: "<CLIENT_SECRET>",        OIDC_AUTHORITY: "<AUTH_URL>

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.

oidc:  disabled: false  client_id: <client_id>  client_secret: <client_secret>  authority: <auth_url>  redirect_uri: <host>

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!