Zum Hauptinhalt springen

DolphinScheduler, IoTDB und andere Apache-Datenplattformen: SSO mit Casdoor

· 10 Minuten Lektüre
Yang Luo
Yang Luo
Casdoor Maintainer

Mehrere Apache-Daten- und Middleware-Projekte bringen ihre eigene Casdoor-Anmeldung mit: Apache DolphinScheduler hat einen Authentifizierungstyp namens CASDOOR_SSO (seit 3.2.0) und einen generischen OIDC-Modus (seit 3.4.0), Apache ShenYu hat ein Casdoor-Plugin (seit 2.5.1), Apache Pulsar Manager hat eine „Log in with Casdoor“-Schaltfläche (seit 0.3.0), und Apache APISIX hat das authz-casdoor-Plugin (seit 2.14.0). Apache IoTDB ist die Ausnahme: Die Datenbank selbst authentifiziert sich mit ihren eigenen Benutzern und Passwörtern, und nur die inzwischen archivierte IoTDB Web Workbench kommuniziert mit Casdoor. Die folgende Tabelle listet jedes Projekt, die Version und den Ort der Einstellungen auf; der zweite Teil des Artikels richtet die Benutzerauthentifizierung in IoTDB Schritt für Schritt ein.

Welche Apache-Projekte unterstützen Casdoor​

Alle Fakten in dieser Tabelle stammen aus dem Quellcode-Baum und den Release-Tags jedes Projekts, überprüft am 2026-11-02.

ProjektWie es sich mit Casdoor verbindetErste VeröffentlichungEinstellungen
Apache DolphinSchedulerIntegrierter CASDOOR_SSO-Authentifizierungstyp (Casdoor Java SDK, OAuth 2.0 Code Flow)3.2.0security.authentication.type, casdoor.* in dolphinscheduler-api/src/main/resources/application.yaml
Apache DolphinSchedulerGenerischer OIDC-Login (Spring Security)3.4.0security.authentication.oidc.* in derselben Datei
Apache IoTDB Web WorkbenchCasdoor-Login in der Web-Konsolekein getaggter Release, Repository archiviertcasdoor.* in backend/src/main/resources/application.properties, VUE_APP_CASDOOR in frontend/.env
Apache IoTDB (Server)Native Benutzer und Rollen; ein OpenIdAuthorizer existierte bis 2.0.8 und wurde entferntn/asiehe IoTDB-Abschnitt unten
Apache ShenYuCasdoor-Plugin auf dem Gateway2.5.1Plugin-Konfiguration endpoint, client_id, client_secrect, certificate, organization-name, application-name
Apache Pulsar Manager„Log in with Casdoor“-Schaltfläche neben dem Passwortformular0.3.0casdoor.* in src/main/resources/application.properties; Frontend-Konfiguration in front-end/src/main.js seit 0.4.0
Apache ShardingSphere ElasticJob UI„Login with Casdoor“-Schaltflächenur master, nach 3.0.2casdoor.* in der Backend-application.properties
Apache APISIXauthz-casdoor-Plugin oder openid-connect2.14.0endpoint_addr, client_id, client_secret, callback_url
RuoYi-Cloud (kein Apache-Projekt)Codeänderungen mit dem Casdoor Spring Boot SDKn/aIhr eigenes Login-Controller

Jede SDK-basierte Integration in der Tabelle folgt demselben Muster. Sie erstellen eine Anwendung in Casdoor, kopieren deren Client ID, Client Secret und das öffentliche Zertifikat des Token-Zertifikats und fügen diese zusammen mit den Namen der Organisation und der Anwendung in die Konfiguration des Projekts ein. Das Projekt leitet den Browser an Casdoor weiter, erhält einen Autorisierungscode, tauscht ihn gegen ein JWT aus und überprüft das JWT mit dem Zertifikat. Das Zertifikat ist das unter Certs in der Casdoor-Admin-Konsole; siehe Zertifikate und das Feld Token cert in der Anwendungs-Einstellungsreferenz.

Apache DolphinScheduler​

DolphinScheduler bietet Ihnen zwei Möglichkeiten.

CASDOOR_SSO existiert seit 3.2.0. Setzen Sie den Typ und füllen Sie den obersten casdoor-Block von dolphinscheduler-api/src/main/resources/application.yaml aus:

security:
  authentication:
    type: CASDOOR_SSO
    casdoor:
      user:
        admin: "alice"   # this Casdoor user becomes a DolphinScheduler admin
casdoor:
  endpoint: https://door.example.com
  client-id: <client id>
  client-secret: <client secret>
  certificate: |-
    -----BEGIN CERTIFICATE-----
    ...
    -----END CERTIFICATE-----
  organization-name: my-org
  application-name: app-dolphinscheduler
  redirect-url: http://localhost:5173/login

redirect-url ist die Login-Seite der DolphinScheduler-UI und muss auch in den Redirect URLs der Casdoor-Anwendung enthalten sein. Beim ersten Anmelden erstellt DolphinScheduler einen lokalen Benutzer mit dem Casdoor-Benutzernamen und der E-Mail-Adresse. Der in security.authentication.casdoor.user.admin genannte Benutzer erhält den Admin-Typ; alle anderen werden zu allgemeinen Benutzern. In unserem DolphinScheduler-Leitfaden finden Sie Screenshots.

OIDC wurde in 3.4.0 eingeführt. Es ist generisch, sodass Casdoor als normaler Issuer funktioniert. Die Discovery-Funktion von Spring Security erfordert, dass der konfigurierte Issuer mit dem issuer im Discovery-Dokument übereinstimmt, und da der Issuer von Casdoor der Ursprung seines Backends ist, ist issuer-uri einfach die Casdoor-URL:

api:
  base-url: https://ds.example.com/dolphinscheduler
  ui-url: https://ds.example.com
security:
  authentication:
    type: OIDC
    oidc:
      enable: true
      providers:
        casdoor:
          display-name: "Login with Casdoor"
          issuer-uri: https://door.example.com
          client-id: <client id>
          client-secret: <client secret>
          scope: openid, profile, email
          user-name-attribute: preferred_username
          groups-claim: groups
      user:
        auto-create: true
        default-tenant-code: "default"
        default-queue: "default"
        admin-group-mapping:
          - my-org/ds-admins

Die in Casdoor zu registrierende Redirect-URL ist https://ds.example.com/dolphinscheduler/login/oauth2/code/casdoor, also api.base-url plus /login/oauth2/code/ plus der Provider-Key. Mit dem profile-Scope gibt der UserInfo-Endpoint von Casdoor preferred_username und groups zurück. Standardmäßig kommen Gruppen als my-org/ds-admins. Wenn Sie lieber ds-admins in admin-group-mapping schreiben möchten, setzen Sie Token group format auf Name (group) in der Anwendung. Wenn auto-create false ist (der Upstream-Standard), können sich nur Benutzer anmelden, die bereits in DolphinScheduler existieren. Im Leitfaden für Standard-OIDC-Clients wird aufgelistet, was das Discovery-Dokument und UserInfo zurückgeben.

Apache ShenYu​

Das Casdoor-Plugin ist seit 2.5.1 im ShenYu-Gateway enthalten. Sie aktivieren es in der ShenYu-Admin-Konsole und füllen die Plugin-Daten aus. Zwei Details stammen aus dem Quellcode statt aus der Dokumentation. Erstens: Der Secret Key wird als client_secrect geschrieben. Zweitens: Das Zertifikatsfeld ist einzeilig, daher schreiben Sie \n, wo sonst ein Zeilenumbruch wäre. Das Plugin akzeptiert ein JWT aus dem Authorization-Header oder einen code und state in der Query String. Dann übergibt es den Benutzer nachgelagert in den Headern name, id und organization. Anfragen, die weder eines davon enthalten, werden mit einem Token-Fehler abgelehnt, nicht umgeleitet. Auf dem Master-Branch von ShenYu (Oktober 2026) wurde das Plugin aus dem Hauptrepository in den ShenYu-Plugin-Store verschoben. Der Plugin-Name, die Felder und Header blieben gleich, und Sie fügen den Starter shenyu-spring-boot-starter-plugin-casdoor selbst hinzu. Siehe Casdoor in ShenYu verwenden.

Apache Pulsar Manager und ShardingSphere ElasticJob UI​

Pulsar Manager hat Casdoor in 0.3.0 hinzugefügt. Das Backend liest casdoor.endpoint, casdoor.clientId, casdoor.clientSecret, casdoor.certificate, casdoor.organizationName und casdoor.applicationName aus src/main/resources/application.properties. Seit 0.4.0 verwendet das Frontend casdoor-vue-sdk, konfiguriert in front-end/src/main.js mit serverUrl, clientId, organizationName, appName und redirectPath. Ein Casdoor-Benutzer beim ersten Mal erhält ein lokales Pulsar-Manager-Konto. Siehe Pulsar Manager.

ElasticJob UI, die Konsole von Apache ShardingSphere ElasticJob, hat die Casdoor-Anmeldung im November 2022 integriert. Das war nach seiner letzten Release-Version 3.0.2, daher müssen Sie den Master-Branch bauen. Die Schlüssel verwenden Bindestriche: casdoor.endpoint, casdoor.client-id, casdoor.client-secret, casdoor.certificate, casdoor.organization-name, casdoor.application-name. Siehe ShardingSphere.

Für Apache APISIX sind beide Plugins in APISIX behandelt.

Schritt-für-Schritt-Einrichtung der Benutzerauthentifizierung in Apache IoTDB​

IoTDB authentifiziert jede Sitzung (CLI, JDBC, Session API) mit einem Benutzernamen und Passwort, die von der Datenbank gespeichert werden. Da serverseitig kein Casdoor-Login vorhanden ist, basiert die Einrichtung auf dem nativen Benutzermodell von IoTDB. Die folgenden Anweisungen gelten für das Baummodell. Das Tabellenmodell von IoTDB 2.x hat seine eigene Syntax im Tabellenmodell-Leitfaden.

Schritt 1. Ändern des root-Passworts. root ist der einzige Administrator und kann nicht gelöscht werden. Melden Sie sich über die CLI an und setzen Sie ein starkes Passwort:

ALTER USER root SET PASSWORD 'Str0ng_Passw0rd!';

Schritt 2. Benutzer erstellen. Benutzernamen und Passwörter sind 4 bis 32 Zeichen lang. Sie dürfen Buchstaben, Ziffern und !@#$%^&*()_+-= enthalten, und ab V2.0.7 darf das Passwort nicht dem Benutzernamen entsprechen. TimechoDB, die kommerzielle IoTDB-Distribution von Timecho, erfordert 12 bis 32 Zeichen mit Groß- und Kleinbuchstaben, einer Ziffer und einem Symbol und hat ein anderes Standard-root-Passwort. Ändern Sie es auf dieselbe Weise.

CREATE USER ln_reader 'Read_Passw0rd!';
CREATE USER ops_admin 'Ops_Passw0rd!';

Schritt 3. Gruppieren von Berechtigungen in Rollen. Neue Benutzer haben keine Berechtigungen. Serienberechtigungen (READ_DATA, WRITE_DATA, READ_SCHEMA, WRITE_SCHEMA oder die Aliase READ, WRITE, ALL) werden auf Pfadmuster gewährt:

CREATE ROLE ln_readers;
GRANT READ ON root.ln.** TO ROLE ln_readers;
GRANT ROLE ln_readers TO ln_reader;

Schritt 4. Delegieren der Benutzerverwaltung. Hier unterscheiden sich die Versionen. Ab V2.0.7 sind globale Berechtigungen SYSTEM und SECURITY. Davor waren sie in MANAGE_USER, MANAGE_ROLE, MANAGE_DATABASE und andere aufgeteilt. Globale Berechtigungen werden immer auf root.** gewährt:

-- IoTDB V2.0.7 and later, TimechoDB
GRANT SECURITY ON root.** TO USER ops_admin;
-- before V2.0.7
GRANT MANAGE_USER, MANAGE_ROLE ON root.** TO USER ops_admin;

Schritt 5. Verbinden und überprüfen.

sbin/start-cli.sh -h 127.0.0.1 -p 6667 -u ln_reader -pw 'Read_Passw0rd!'

Führen Sie dann LIST PRIVILEGES OF USER ln_reader; aus. Die effektiven Berechtigungen eines Benutzers sind die Vereinigung seiner eigenen und derjenigen seiner Rollen. Um eine Berechtigung zu entziehen, widerrufen Sie sie sowohl vom Benutzer als auch von jeder Rolle, die sie gewährt.

Was ist mit OIDC in IoTDB?​

Ältere IoTDB-Versionen hatten authorizer_provider_class=org.apache.iotdb.commons.auth.authorizer.OpenIdAuthorizer mit openID_url. Der Client übergab ein Access Token als Benutzernamen mit einem leeren Passwort. Dieser Autorizer war auf Keycloak aufgebaut. Er behandelt einen Benutzer nur dann als Administrator, wenn realm_access.roles im Token iotdb_admin enthält, und jede Berechtigungsprüfung reduziert sich auf diesen Test. Sein Token-Parser setzt außerdem eine nahezu unbegrenzte Clock Skew, was in der Praxis die Token-Ablaufzeit ignoriert. Casdoor gibt realm_access nicht aus, daher war dies nie eine passende Lösung. IoTDB hat es im März 2026 entfernt (apache/iotdb#17320), und es fehlt in den Versionen 2.0.10 und 2.0.11.

Wenn Sie Casdoor-Konten vor IoTDB verwenden möchten, ist die einzige bestehende Option die Integration über IoTDB Web Workbench. Das Repository ist auf GitHub archiviert, betrachten Sie es daher eher als Ausgangspunkt als als gepflegtes Produkt. Die Datenbankverbindung selbst verwendet weiterhin einen IoTDB-Benutzer aus den obigen Schritten.

RuoYi​

RuoYi-Cloud hat keinen Casdoor-Schalter. Unser RuoYi-Leitfaden ersetzt das Passwort-Login durch den Authorization Code Flow von Casdoor über das Casdoor Spring Boot SDK. Es synchronisiert die vorhandenen RuoYi-Benutzer mit einem Syncer in Casdoor unter Verwendung von bcrypt, damit ihre Passwörter weiterhin funktionieren. Für eine einfache Spring Boot-Anwendung beginnen Sie mit Spring Boot SSO mit OIDC.

Referenzen​