Passer au contenu principal

DolphinScheduler, IoTDB et autres plateformes de données Apache : SSO avec Casdoor

· Lecture de 10 minutes
Yang Luo
Yang Luo
Casdoor Maintainer

Plusieurs projets de données et de middleware Apache intègrent leur propre connexion Casdoor : Apache DolphinScheduler dispose d'un type d'authentification appelé CASDOOR_SSO (depuis la 3.2.0) et d'un mode OIDC générique (depuis la 3.4.0), Apache ShenYu dispose d'un plugin Casdoor (depuis la 2.5.1), Apache Pulsar Manager a un bouton "Log in with Casdoor" (depuis la 0.3.0), et Apache APISIX dispose du plugin authz-casdoor (depuis la 2.14.0). Apache IoTDB est l'exception : la base de données elle-même s'authentifie avec ses propres utilisateurs et mots de passe, et seul le Web Workbench IoTDB désormais archivé communique avec Casdoor. Le tableau ci-dessous liste chaque projet, la version, et où se trouvent les paramètres ; la seconde moitié de l'article configure l'authentification des utilisateurs dans IoTDB étape par étape.

Quels projets Apache supportent Casdoor​

Tous les faits dans ce tableau proviennent de l'arborescence source de chaque projet et des tags de release, vérifiés le 2026-11-02.

ProjetComment il se connecte à CasdoorPremière releaseParamètres
Apache DolphinSchedulerType d'authentification intégré CASDOOR_SSO (SDK Java Casdoor, flux de code OAuth 2.0)3.2.0security.authentication.type, casdoor.* dans dolphinscheduler-api/src/main/resources/application.yaml
Apache DolphinSchedulerConnexion OIDC générique (Spring Security)3.4.0security.authentication.oidc.* dans le même fichier
Apache IoTDB Web WorkbenchConnexion Casdoor dans la console webaucune release taguée, dépôt archivécasdoor.* dans backend/src/main/resources/application.properties, VUE_APP_CASDOOR dans frontend/.env
Apache IoTDB (serveur)Utilisateurs et rôles natifs ; un OpenIdAuthorizer existait jusqu'à la 2.0.8 et a été supprimén/avoir la section IoTDB ci-dessous
Apache ShenYuPlugin Casdoor sur la passerelle2.5.1config du plugin endpoint, client_id, client_secrect, certificate, organization-name, application-name
Apache Pulsar ManagerBouton "Log in with Casdoor" à côté du formulaire de mot de passe0.3.0casdoor.* dans src/main/resources/application.properties ; config front-end dans front-end/src/main.js depuis la 0.4.0
Apache ShardingSphere ElasticJob UIBouton "Login with Casdoor"master uniquement, après la 3.0.2casdoor.* dans le application.properties du backend
Apache APISIXPlugin authz-casdoor, ou openid-connect2.14.0endpoint_addr, client_id, client_secret, callback_url
RuoYi-Cloud (pas un projet Apache)Modifications de code avec le SDK Spring Boot Casdoorn/avotre propre contrôleur de connexion

Chaque intégration basée sur un SDK dans le tableau suit le même modèle. Vous créez une application dans Casdoor, copiez son ID client, son secret client et le certificat public de son certificat de jeton, puis collez-les dans la configuration du projet avec les noms de l'organisation et de l'application. Le projet redirige le navigateur vers Casdoor, reçoit un code d'autorisation, l'échange contre un JWT et vérifie le JWT avec le certificat. Le certificat est celui sous Certs dans la console d'administration de Casdoor ; consultez certificates et le champ Token cert dans la référence des paramètres de l'application.

Apache DolphinScheduler​

DolphinScheduler propose deux méthodes d'intégration.

CASDOOR_SSO existe depuis la version 3.2.0. Définissez le type et remplissez le bloc casdoor de premier niveau dans dolphinscheduler-api/src/main/resources/application.yaml :

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 est la page de connexion de l'interface utilisateur de DolphinScheduler, et elle doit également figurer dans les Redirect URLs de l'application Casdoor. Lors de la première connexion, DolphinScheduler crée un utilisateur local avec le nom d'utilisateur et l'e-mail de Casdoor. L'utilisateur spécifié dans security.authentication.casdoor.user.admin obtient le type administrateur ; tous les autres deviennent des utilisateurs généraux. Notre guide DolphinScheduler contient les captures d'écran.

OIDC a été introduit dans la version 3.4.0. Il est générique, donc Casdoor fonctionne comme un émetteur ordinaire. La découverte de Spring Security exige que l'émetteur configuré corresponde à l'issuer dans le document de découverte, et l'émetteur de Casdoor est l'origine de son backend, donc issuer-uri est simplement l'URL de Casdoor :

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

L'URL de redirection à enregistrer dans Casdoor est https://ds.example.com/dolphinscheduler/login/oauth2/code/casdoor, c'est-à-dire api.base-url plus /login/oauth2/code/ plus la clé du fournisseur. Avec la portée profile, le point de terminaison UserInfo de Casdoor renvoie preferred_username et groups. Par défaut, les groupes arrivent sous la forme my-org/ds-admins. Définissez Token group format sur Name (group) dans l'application si vous préférez écrire ds-admins dans admin-group-mapping. Si auto-create est false (la valeur par défaut en amont), seuls les utilisateurs existant déjà dans DolphinScheduler peuvent se connecter. Le guide client OIDC standard liste ce que le document de découverte et UserInfo renvoient.

Apache ShenYu​

Le plugin Casdoor est fourni avec la passerelle ShenYu depuis la version 2.5.1. Vous l'activez dans la console d'administration de ShenYu et remplissez les données du plugin. Deux détails proviennent du code source plutôt que de la documentation. Premièrement, la clé secrète est orthographiée client_secrect. Deuxièmement, le champ du certificat est une seule ligne, donc vous écrivez \n là où chaque saut de ligne va. Le plugin accepte un JWT dans l'en-tête Authorization, ou un code et un state dans la chaîne de requête. Il transmet ensuite l'utilisateur en aval dans les en-têtes name, id et organization. Les requêtes qui ne contiennent ni l'un ni l'autre sont rejetées avec une erreur de jeton, sans redirection. Sur la branche master de ShenYu (octobre 2026), le plugin a été déplacé du dépôt principal vers la boutique de plugins ShenYu. Le nom du plugin, les champs et les en-têtes sont restés les mêmes, et vous ajoutez vous-même le starter shenyu-spring-boot-starter-plugin-casdoor. Consultez Utiliser Casdoor dans ShenYu.

Apache Pulsar Manager et ShardingSphere ElasticJob UI​

Pulsar Manager a ajouté Casdoor dans la version 0.3.0. Le backend lit casdoor.endpoint, casdoor.clientId, casdoor.clientSecret, casdoor.certificate, casdoor.organizationName et casdoor.applicationName depuis src/main/resources/application.properties. Depuis la version 0.4.0, le frontend utilise casdoor-vue-sdk, configuré dans front-end/src/main.js avec serverUrl, clientId, organizationName, appName et redirectPath. Un nouvel utilisateur Casdoor obtient un compte local Pulsar Manager. Consultez Pulsar Manager.

ElasticJob UI, la console d'Apache ShardingSphere ElasticJob, a intégré la connexion Casdoor en novembre 2022. Cela s'est fait après sa dernière version stable, 3.0.2, donc vous devez compiler la branche master. Les clés utilisent des tirets : casdoor.endpoint, casdoor.client-id, casdoor.client-secret, casdoor.certificate, casdoor.organization-name, casdoor.application-name. Consultez ShardingSphere.

Pour Apache APISIX, les deux plugins sont couverts dans APISIX.

Configuration étape par étape de l'authentification des utilisateurs dans Apache IoTDB​

IoTDB authentifie chaque session (CLI, JDBC, API Session) avec un nom d'utilisateur et un mot de passe stockés par la base de données. Comme il n'y a pas de connexion Casdoor côté serveur, la configuration utilise le modèle d'utilisateur natif d'IoTDB. Les instructions ci-dessous concernent le modèle hiérarchique (tree model). Le modèle tabulaire (table model) d'IoTDB 2.x possède sa propre syntaxe dans le guide du modèle tabulaire.

Étape 1. Changer le mot de passe root. root est le seul administrateur et ne peut pas être supprimé. Connectez-vous avec le CLI et définissez un mot de passe fort :

ALTER USER root SET PASSWORD 'Str0ng_Passw0rd!';

Étape 2. Créer des utilisateurs. Les noms d'utilisateur et les mots de passe ont entre 4 et 32 caractères. Ils peuvent contenir des lettres, des chiffres et !@#$%^&*()_+-=, et depuis la V2.0.7, un mot de passe ne peut pas être identique au nom d'utilisateur. TimechoDB, la distribution commerciale d'IoTDB par Timecho, exige entre 12 et 32 caractères avec des majuscules, des minuscules, un chiffre et un symbole, et possède un mot de passe root par défaut différent. Changez-le de la même manière.

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

Étape 3. Regrouper les privilèges dans des rôles. Les nouveaux utilisateurs n'ont aucun privilège. Les privilèges de série (READ_DATA, WRITE_DATA, READ_SCHEMA, WRITE_SCHEMA, ou les alias READ, WRITE, ALL) sont accordés sur des motifs de chemin :

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

Étape 4. Déléguer la gestion des utilisateurs. C'est ici que les versions diffèrent. À partir de la V2.0.7, les privilèges globaux sont SYSTEM et SECURITY. Avant cela, ils étaient divisés en MANAGE_USER, MANAGE_ROLE, MANAGE_DATABASE et d'autres. Les privilèges globaux sont toujours accordés sur root.** :

-- 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;

Étape 5. Se connecter et vérifier.

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

Exécutez ensuite LIST PRIVILEGES OF USER ln_reader;. Les privilèges effectifs d'un utilisateur sont l'union de ses propres privilèges et de ceux de ses rôles. Pour retirer un privilège, révoquez-le à la fois pour l'utilisateur et pour tous les rôles qui l'accordent.

Qu'en est-il d'OIDC dans IoTDB ?​

Les anciennes versions d'IoTDB utilisaient authorizer_provider_class=org.apache.iotdb.commons.auth.authorizer.OpenIdAuthorizer avec openID_url. Le client passait un jeton d'accès comme nom d'utilisateur avec un mot de passe vide. Cet authorizer était conçu autour de Keycloak. Il considère un utilisateur comme administrateur uniquement si les realm_access.roles du jeton contiennent iotdb_admin, et chaque vérification de privilège se réduit à ce test. Son analyseur de jetons définit également un décalage horaire quasi infini, qui ignore en pratique l'expiration des jetons. Casdoor n'émet pas realm_access, ce protocole n'a donc jamais été adapté. IoTDB l'a supprimé en mars 2026 (apache/iotdb#17320), et il est absent des versions 2.0.10 et 2.0.11.

Si vous souhaitez utiliser des comptes Casdoor devant IoTDB, la seule option existante est l'intégration IoTDB Web Workbench. Son dépôt GitHub est archivé, considérez-le donc comme un point de départ plutôt que comme un produit maintenu. La connexion à la base de données elle-même utilise toujours un utilisateur IoTDB défini selon les étapes ci-dessus.

RuoYi​

RuoYi-Cloud ne propose pas d'option directe pour Casdoor. Notre guide RuoYi remplace la connexion par mot de passe par le flux de code d'autorisation Casdoor via le SDK Spring Boot de Casdoor. Il synchronise les utilisateurs RuoYi existants dans Casdoor à l'aide d'un syncer, en utilisant bcrypt afin que leurs mots de passe restent valides. Pour une application Spring Boot standard, commencez par SSO Spring Boot avec OIDC.

Références​