Saltar al contenido principal

DolphinScheduler, IoTDB y otras plataformas de datos de Apache: SSO con Casdoor

· 11 min de lectura
Yang Luo
Yang Luo
Casdoor Maintainer

Varios proyectos de datos y middleware de Apache incluyen su propio inicio de sesión de Casdoor: Apache DolphinScheduler tiene un tipo de autenticación llamado CASDOOR_SSO (desde 3.2.0) y un modo OIDC genérico (desde 3.4.0), Apache ShenYu tiene un plugin de Casdoor (desde 2.5.1), Apache Pulsar Manager tiene un botón "Log in with Casdoor" (desde 0.3.0), y Apache APISIX tiene el plugin authz-casdoor (desde 2.14.0). Apache IoTDB es la excepción: la base de datos en sí autentica con sus propios usuarios y contraseñas, y solo la ahora archivada IoTDB Web Workbench se comunica con Casdoor. La tabla siguiente lista cada proyecto, la versión y dónde residen los ajustes; la segunda mitad del artículo configura paso a paso la autenticación de usuarios en IoTDB.

Qué proyectos de Apache soportan Casdoor​

Todos los hechos en esta tabla provienen del árbol de código fuente y las etiquetas de versión de cada proyecto, verificados el 2026-11-02.

ProyectoCómo se conecta a CasdoorPrimera versiónAjustes
Apache DolphinSchedulerTipo de autenticación CASDOOR_SSO integrado (SDK Java de Casdoor, flujo de código OAuth 2.0)3.2.0security.authentication.type, casdoor.* en dolphinscheduler-api/src/main/resources/application.yaml
Apache DolphinSchedulerInicio de sesión OIDC genérico (Spring Security)3.4.0security.authentication.oidc.* en el mismo archivo
Apache IoTDB Web WorkbenchInicio de sesión de Casdoor en la consola websin etiqueta de versión, repositorio archivadocasdoor.* en backend/src/main/resources/application.properties, VUE_APP_CASDOOR en frontend/.env
Apache IoTDB (servidor)Usuarios y roles nativos; existió un OpenIdAuthorizer hasta la 2.0.8 y fue eliminadon/avea la sección de IoTDB abajo
Apache ShenYuPlugin de Casdoor en la pasarela2.5.1configuración del plugin endpoint, client_id, client_secrect, certificate, organization-name, application-name
Apache Pulsar ManagerBotón "Log in with Casdoor" junto al formulario de contraseña0.3.0casdoor.* en src/main/resources/application.properties; configuración de front-end en front-end/src/main.js desde 0.4.0
Apache ShardingSphere ElasticJob UIBotón "Login with Casdoor"solo master, después de 3.0.2casdoor.* en el application.properties del backend
Apache APISIXPlugin authz-casdoor, u openid-connect2.14.0endpoint_addr, client_id, client_secret, callback_url
RuoYi-Cloud (no es un proyecto de Apache)Cambios de código con el SDK Spring Boot de Casdoorn/asu propio controlador de inicio de sesión

Cada integración basada en SDK de la tabla sigue el mismo patrón. Creas una aplicación en Casdoor, copias su ID de cliente, secreto de cliente y el certificado público de su token cert, y los pegas en la configuración del proyecto junto con los nombres de la organización y de la aplicación. El proyecto redirige el navegador a Casdoor, recibe un código de autorización, lo intercambia por un JWT y verifica el JWT con el certificado. El certificado es el que se encuentra bajo Certs en la consola de administración de Casdoor; consulta certificates y el campo Token cert en la referencia de configuración de aplicaciones.

Apache DolphinScheduler​

DolphinScheduler te ofrece dos formas de integrarse.

CASDOOR_SSO existe desde la versión 3.2.0. Establece el tipo y completa el bloque casdoor de nivel superior en 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 es la página de inicio de sesión de la interfaz de usuario de DolphinScheduler, y también debe estar incluida en las Redirect URLs de la aplicación de Casdoor. En el primer inicio de sesión, DolphinScheduler crea un usuario local con el nombre de usuario y el correo electrónico de Casdoor. El usuario especificado en security.authentication.casdoor.user.admin obtiene el tipo de administrador; todos los demás se convierten en usuarios generales. Nuestra guía de DolphinScheduler incluye capturas de pantalla.

OIDC llegó en la versión 3.4.0. Es genérico, por lo que Casdoor funciona como un emisor ordinario. El descubrimiento de Spring Security requiere que el emisor configurado coincida con el issuer en el documento de descubrimiento, y el emisor de Casdoor es el origen de su backend, por lo que issuer-uri es simplemente la 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

La URL de redirección que debes registrar en Casdoor es https://ds.example.com/dolphinscheduler/login/oauth2/code/casdoor, es decir, api.base-url más /login/oauth2/code/ más la clave del proveedor. Con el ámbito profile, el endpoint UserInfo de Casdoor devuelve preferred_username y groups. De forma predeterminada, los grupos llegan como my-org/ds-admins. Establece Token group format en Name (group) en la aplicación si prefieres escribir ds-admins en admin-group-mapping. Si auto-create es false (el valor predeterminado original), solo pueden iniciar sesión los usuarios que ya existen en DolphinScheduler. La guía de cliente OIDC estándar detalla lo que devuelven el documento de descubrimiento y UserInfo.

Apache ShenYu​

El plugin de Casdoor se ha incluido con la puerta de enlace ShenYu desde la versión 2.5.1. Lo activas en la consola de administración de ShenYu y completas los datos del plugin. Dos detalles provienen del código fuente en lugar de la documentación. Primero, la clave secreta está escrita como client_secrect. Segundo, el campo del certificado es de una sola línea, por lo que debes escribir \n donde corresponda cada salto de línea. El plugin acepta un JWT desde el encabezado Authorization, o un code y state en la cadena de consulta. Luego pasa el usuario aguas abajo en los encabezados name, id y organization. Las solicitudes que no llevan ninguno de estos son rechazadas con un error de token, no redirigidas. En la rama master de ShenYu (octubre de 2026), el plugin se movió del repositorio principal a la tienda de plugins de ShenYu. El nombre del plugin, los campos y los encabezados permanecieron iguales, y debes agregar tú mismo el starter shenyu-spring-boot-starter-plugin-casdoor. Consulta Using Casdoor in ShenYu.

Apache Pulsar Manager y ShardingSphere ElasticJob UI​

Pulsar Manager añadió Casdoor en la versión 0.3.0. El backend lee casdoor.endpoint, casdoor.clientId, casdoor.clientSecret, casdoor.certificate, casdoor.organizationName y casdoor.applicationName desde src/main/resources/application.properties. Desde la versión 0.4.0, el frontend utiliza casdoor-vue-sdk, configurado en front-end/src/main.js con serverUrl, clientId, organizationName, appName y redirectPath. Un usuario nuevo de Casdoor obtiene una cuenta local en Pulsar Manager. Consulta Pulsar Manager.

ElasticJob UI, la consola de Apache ShardingSphere ElasticJob, fusionó el inicio de sesión de Casdoor en noviembre de 2022. Esto fue después de su última versión, la 3.0.2, por lo que necesitas compilar la rama master. Las claves usan guiones: casdoor.endpoint, casdoor.client-id, casdoor.client-secret, casdoor.certificate, casdoor.organization-name, casdoor.application-name. Consulta ShardingSphere.

Para Apache APISIX, ambos plugins están cubiertos en APISIX.

Configuración paso a paso de la autenticación de usuarios en Apache IoTDB​

IoTDB autentica cada sesión (CLI, JDBC, API de sesión) con un nombre de usuario y contraseña almacenados por la base de datos. Dado que no hay un inicio de sesión de Casdoor en el lado del servidor, la configuración sigue el modelo de usuario nativo de IoTDB. Las siguientes instrucciones son para el modelo de árbol. El modelo de tablas de IoTDB 2.x tiene su propia sintaxis en la guía del modelo de tablas.

Paso 1. Cambia la contraseña de root. root es el único administrador y no puede eliminarse. Inicia sesión con la CLI y establece una contraseña fuerte:

ALTER USER root SET PASSWORD 'Str0ng_Passw0rd!';

Paso 2. Crea usuarios. Los nombres de usuario y contraseñas deben tener entre 4 y 32 caracteres. Pueden contener letras, dígitos y !@#$%^&*()_+-=, y desde V2.0.7 una contraseña no puede ser igual al nombre de usuario. TimechoDB, la distribución comercial de IoTDB de Timecho, requiere entre 12 y 32 caracteres con mayúsculas, minúsculas, un dígito y un símbolo, y tiene una contraseña raíz predeterminada diferente. Cámbiala de la misma manera.

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

Paso 3. Agrupa privilegios en roles. Los nuevos usuarios no tienen privilegios. Los privilegios de serie (READ_DATA, WRITE_DATA, READ_SCHEMA, WRITE_SCHEMA, o los alias READ, WRITE, ALL) se otorgan sobre patrones de ruta:

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

Paso 4. Delega la gestión de usuarios. Aquí es donde difieren las versiones. Desde V2.0.7, los privilegios globales son SYSTEM y SECURITY. Antes de eso, estaban divididos en MANAGE_USER, MANAGE_ROLE, MANAGE_DATABASE y otros. Los privilegios globales siempre se otorgan sobre 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;

Paso 5. Conecta y verifica.

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

Luego ejecuta LIST PRIVILEGES OF USER ln_reader;. Los privilegios efectivos de un usuario son la unión de los suyos propios y los de sus roles. Para quitar un privilegio, revócalo tanto del usuario como de cada rol que lo otorgue.

¿Qué hay del OIDC en IoTDB?​

Las versiones más antiguas de IoTDB tenían authorizer_provider_class=org.apache.iotdb.commons.auth.authorizer.OpenIdAuthorizer con openID_url. El cliente pasaba un token de acceso como nombre de usuario con una contraseña vacía. Ese autorizador estaba diseñado alrededor de Keycloak. Trata a un usuario como administrador solo si el campo realm_access.roles del token contiene iotdb_admin, y cada verificación de privilegios se reduce a esa prueba. Su analizador de tokens también establece una tolerancia de reloj casi infinita, lo que en la práctica ignora la expiración del token. Casdoor no emite realm_access, por lo que nunca fue una opción viable. IoTDB lo eliminó en marzo de 2026 (apache/iotdb#17320), y está ausente en las versiones 2.0.10 y 2.0.11.

Si desea utilizar cuentas de Casdoor frente a IoTDB, la única opción existente es la integración IoTDB Web Workbench. Su repositorio está archivado en GitHub, así que considérelo como un punto de partida en lugar de un producto mantenido. La conexión a la base de datos en sí sigue utilizando un usuario de IoTDB de los pasos anteriores.

RuoYi​

RuoYi-Cloud no tiene una opción para cambiar a Casdoor. Nuestra guía de RuoYi reemplaza su inicio de sesión por contraseña con el flujo de código de autorización de Casdoor a través del SDK de Spring Boot de Casdoor. Sincroniza los usuarios existentes de RuoYi con Casdoor mediante un sincronizador, usando bcrypt para que sus contraseñas sigan funcionando. Para una aplicación Spring Boot estándar, comience con SSO con OIDC en Spring Boot.

Referencias​