Pular para o conteúdo principal

DolphinScheduler, IoTDB e Outras Plataformas de Dados Apache: SSO com Casdoor

· Leitura de 10 min
Yang Luo
Yang Luo
Casdoor Maintainer

Vários projetos de dados e middleware Apache incluem seu próprio login Casdoor: o Apache DolphinScheduler tem um tipo de autenticação chamado CASDOOR_SSO (desde a 3.2.0) e um modo OIDC genérico (desde a 3.4.0), o Apache ShenYu tem um plugin Casdoor (desde a 2.5.1), o Apache Pulsar Manager tem um botão "Log in with Casdoor" (desde a 0.3.0) e o Apache APISIX tem o plugin authz-casdoor (desde a 2.14.0). O Apache IoTDB é a exceção: o banco de dados em si autentica com seus próprios usuários e senhas, e apenas o agora arquivado IoTDB Web Workbench se comunica com o Casdoor. A tabela abaixo lista cada projeto, a versão e onde ficam as configurações; a segunda metade do post configura a autenticação de usuários no IoTDB passo a passo.

Quais projetos Apache suportam o Casdoor​

Todos os fatos nesta tabela vêm da árvore de código-fonte e das tags de lançamento de cada projeto, verificados em 2026-11-02.

ProjetoComo ele se conecta ao CasdoorPrimeira versãoConfigurações
Apache DolphinSchedulerTipo de autenticação CASDOOR_SSO integrado (Casdoor Java SDK, fluxo de código OAuth 2.0)3.2.0security.authentication.type, casdoor.* em dolphinscheduler-api/src/main/resources/application.yaml
Apache DolphinSchedulerLogin OIDC genérico (Spring Security)3.4.0security.authentication.oidc.* no mesmo arquivo
Apache IoTDB Web WorkbenchLogin Casdoor no console websem versão marcada, repositório arquivadocasdoor.* em backend/src/main/resources/application.properties, VUE_APP_CASDOOR em frontend/.env
Apache IoTDB (servidor)Usuários e papéis nativos; um OpenIdAuthorizer existiu até a 2.0.8 e foi removidon/aveja a seção IoTDB abaixo
Apache ShenYuPlugin Casdoor no gateway2.5.1configuração do plugin endpoint, client_id, client_secrect, certificate, organization-name, application-name
Apache Pulsar ManagerBotão "Log in with Casdoor" ao lado do formulário de senha0.3.0casdoor.* em src/main/resources/application.properties; configuração do front-end em front-end/src/main.js desde a 0.4.0
Apache ShardingSphere ElasticJob UIBotão "Login with Casdoor"apenas master, após a 3.0.2casdoor.* no application.properties do backend
Apache APISIXPlugin authz-casdoor ou openid-connect2.14.0endpoint_addr, client_id, client_secret, callback_url
RuoYi-Cloud (não é um projeto Apache)Alterações de código com o Casdoor Spring Boot SDKn/aseu próprio controlador de login

Cada integração baseada em SDK na tabela segue o mesmo padrão. Você cria uma aplicação no Casdoor, copia seu client ID, client secret e o certificado público do token cert, e cola-os na configuração do projeto junto com os nomes da organização e da aplicação. O projeto redireciona o navegador para o Casdoor, recebe um código de autorização, troca-o por um JWT e verifica o JWT com o certificado. O certificado é aquele encontrado sob Certs no console de administração do Casdoor; consulte certificates e o campo Token cert na referência de configurações da aplicação.

Apache DolphinScheduler​

O DolphinScheduler oferece duas formas de integração.

CASDOOR_SSO está presente desde a versão 3.2.0. Defina o tipo e preencha o bloco casdoor de nível superior em 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 é a página de login da interface do usuário (UI) do DolphinScheduler, e também deve estar incluída nas Redirect URLs da aplicação no Casdoor. No primeiro login, o DolphinScheduler cria um usuário local com o nome de usuário e o e-mail do Casdoor. O usuário especificado em security.authentication.casdoor.user.admin recebe o tipo admin; todos os outros tornam-se usuários comuns. Nosso guia do DolphinScheduler contém as capturas de tela.

OIDC chegou na versão 3.4.0. É genérico, então o Casdoor funciona como um emissor (issuer) comum. A descoberta do Spring Security exige que o emissor configurado corresponda ao issuer no documento de descoberta, e o emissor do Casdoor é a origem de seu backend, portanto issuer-uri é apenas a URL do 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

A URL de redirecionamento a ser registrada no Casdoor é https://ds.example.com/dolphinscheduler/login/oauth2/code/casdoor, ou seja, api.base-url mais /login/oauth2/code/ mais a chave do provedor. Com o escopo profile, o endpoint UserInfo do Casdoor retorna preferred_username e groups. Por padrão, os grupos chegam como my-org/ds-admins. Defina Token group format como Name (group) na aplicação se você preferir escrever ds-admins em admin-group-mapping. Se auto-create for false (o padrão upstream), apenas usuários que já existem no DolphinScheduler poderão fazer login. O guia de cliente OIDC padrão lista o que o documento de descoberta e o UserInfo retornam.

Apache ShenYu​

O plugin do Casdoor foi incluído no gateway ShenYu desde a versão 2.5.1. Você o ativa no console de administração do ShenYu e preenche os dados do plugin. Dois detalhes vêm do código-fonte, não da documentação. Primeiro, a chave secreta é grafada como client_secrect. Segundo, o campo do certificado é de linha única, então você escreve \n onde cada quebra de linha vai. O plugin aceita um JWT do cabeçalho Authorization, ou um code e state na string de consulta (query string). Ele então passa o usuário adiante nos cabeçalhos name, id e organization. Requisições que não contêm nenhum desses são rejeitadas com um erro de token, sem redirecionamento. Na branch master do ShenYu (outubro de 2026), o plugin foi movido do repositório principal para a loja de plugins do ShenYu. O nome do plugin, campos e cabeçalhos permaneceram os mesmos, e você adiciona o starter shenyu-spring-boot-starter-plugin-casdoor manualmente. Consulte Using Casdoor in ShenYu.

Apache Pulsar Manager e ShardingSphere ElasticJob UI​

O Pulsar Manager adicionou suporte ao Casdoor na versão 0.3.0. O backend lê casdoor.endpoint, casdoor.clientId, casdoor.clientSecret, casdoor.certificate, casdoor.organizationName e casdoor.applicationName de src/main/resources/application.properties. Desde a versão 0.4.0, o frontend usa casdoor-vue-sdk, configurado em front-end/src/main.js com serverUrl, clientId, organizationName, appName e redirectPath. Um usuário novo do Casdoor ganha uma conta local no Pulsar Manager. Consulte Pulsar Manager.

O ElasticJob UI, o console do Apache ShardingSphere ElasticJob, incorporou o login via Casdoor em novembro de 2022. Isso foi após sua última versão, 3.0.2, então você precisa compilar a branch master. As chaves usam hífens: casdoor.endpoint, casdoor.client-id, casdoor.client-secret, casdoor.certificate, casdoor.organization-name, casdoor.application-name. Consulte ShardingSphere.

Para o Apache APISIX, ambos os plugins estão cobertos em APISIX.

Configuração passo a passo de autenticação de usuários no Apache IoTDB​

O IoTDB autentica cada sessão (CLI, JDBC, Session API) com um nome de usuário e senha armazenados pelo banco de dados. Como não há login do Casdoor no lado do servidor, a configuração usa o modelo de usuário nativo do IoTDB. As instruções abaixo são para o modelo de árvore (tree model). O modelo de tabela (table model) do IoTDB 2.x tem sua própria sintaxe no guia do modelo de tabela.

Passo 1. Altere a senha do root. root é o único administrador e não pode ser excluído. Faça login com a CLI e defina uma senha forte:

ALTER USER root SET PASSWORD 'Str0ng_Passw0rd!';

Passo 2. Crie usuários. Nomes de usuário e senhas têm entre 4 e 32 caracteres. Eles podem conter letras, dígitos e !@#$%^&*()_+-=, e, a partir da V2.0.7, a senha não pode ser igual ao nome de usuário. O TimechoDB, a distribuição comercial do IoTDB pela Timecho, requer de 12 a 32 caracteres com maiúsculas e minúsculas, um dígito e um símbolo, e possui uma senha root padrão diferente. Altere-a da mesma forma.

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

Passo 3. Agrupe privilégios em funções (roles). Novos usuários não têm privilégios. Privilégios de série (READ_DATA, WRITE_DATA, READ_SCHEMA, WRITE_SCHEMA, ou os aliases READ, WRITE, ALL) são concedidos sobre padrões de caminho (path patterns):

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

Passo 4. Delegue o gerenciamento de usuários. É aqui que as versões diferem. A partir da V2.0.7, os privilégios globais são SYSTEM e SECURITY. Antes disso, eles eram divididos em MANAGE_USER, MANAGE_ROLE, MANAGE_DATABASE e outros. Privilégios globais são sempre concedidos 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;

Passo 5. Conecte e verifique.

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

Em seguida, execute LIST PRIVILEGES OF USER ln_reader;. Os privilégios efetivos de um usuário são a união dos seus próprios privilégios e aqueles de suas funções (roles). Para remover um privilégio, revogue-o tanto do usuário quanto de todas as funções que o concedem.

E quanto ao OIDC no IoTDB?​

Versões mais antigas do IoTDB usavam authorizer_provider_class=org.apache.iotdb.commons.auth.authorizer.OpenIdAuthorizer com openID_url. O cliente passava um token de acesso como nome de usuário com uma senha vazia. Esse autorizador foi construído em torno do Keycloak. Ele trata um usuário como administrador apenas se realm_access.roles do token contiver iotdb_admin, e cada verificação de privilégio se reduz a esse teste. Seu parser de tokens também define um skew de relógio quase infinito, o que na prática ignora a expiração do token. O Casdoor não emite realm_access, portanto, isso nunca foi adequado. O IoTDB removeu isso em março de 2026 (apache/iotdb#17320), e está ausente nas versões 2.0.10 e 2.0.11.

Se você deseja contas do Casdoor na frente do IoTDB, a opção existente é a integração do IoTDB Web Workbench. Seu repositório está arquivado no GitHub, então trate-o como um ponto de partida, não como um produto mantido. A conexão com o banco de dados em si ainda usa um usuário do IoTDB dos passos acima.

RuoYi​

O RuoYi-Cloud não possui uma chave de alternância para o Casdoor. Nosso guia do RuoYi substitui seu login por senha pelo fluxo de código de autorização do Casdoor através do SDK Spring Boot do Casdoor. Ele sincroniza os usuários existentes do RuoYi no Casdoor com um syncer, usando bcrypt para que suas senhas continuem funcionando. Para uma aplicação Spring Boot simples, comece com SSO Spring Boot com OIDC.

Referências​