6 posts marcados com "OIDC"

Cada ferramenta em uma típica stack DevOps auto-hospedada pode atuar como um cliente OpenID Connect: Gitea e Argo CD suportam OIDC nativamente, Jenkins faz isso através do plugin oic-auth, Grafana e Portainer através de OAuth 2.0 genérico, e MinIO, Harbor e GitLab através de suas configurações OIDC. Aponte todas elas para uma única instância do Casdoor, dê a cada ferramenta sua própria aplicação no Casdoor e coloque seus usuários em grupos do Casdoor. Cada ferramenta então lê a claim groups e decide quem é administrador. Este post lista a URL de callback, as chaves de configuração e o mapeamento de grupos para cada ferramenta, depois cobre as partes que elas compartilham.

O nginx open-source não possui um módulo CAS, então "autenticação CAS no nginx" na prática significa uma das duas configurações. Ou o nginx consulta um serviço de autenticação sobre cada solicitação através de seu módulo auth_request, e o Casdoor responde (diretamente em /api/forward-auth, ou através de casdoor-forward-auth ou OAuth2 Proxy), ou o aplicativo atrás do nginx é ele próprio um cliente CAS e conversa com os endpoints do servidor CAS do Casdoor. Se você puder recompilar o nginx, o módulo nginx do Casdoor executa o login dentro do nginx, e se você preferir não executar o nginx, o proxy de site do Casdoor pode ficar na frente do aplicativo. Em todos os casos, a página de login é a do Casdoor, então uma sessão SSO, um conjunto de permissões e uma política MFA cobrem todos os aplicativos.

Desconectar um usuário de um aplicativo OpenID Connect exige mais do que apenas excluir seu próprio cookie de sessão. O usuário ainda está conectado ao provedor de identidade, então o próximo clique em "Sign in" passa direto sem senha, e os outros aplicativos que compartilham essa sessão do provedor de identidade permanecem conectados também. Um logout adequado tem três partes: limpar a sessão local do seu aplicativo, enviar o navegador para o end_session_endpoint do provedor (logout iniciado pelo RP) para que a sessão do provedor seja encerrada e permitir que o provedor informe os outros aplicativos através do logout back-channel. No Casdoor, o endpoint de fim de sessão é /api/logout, o logout back-channel é configurado por aplicação e os refresh tokens podem ser revogados em /api/login/oauth/revoke.

Para adicionar single sign-on ao Spring Boot, registre cada aplicativo como uma aplicação em um provedor OpenID Connect, como o Casdoor, aponte o Spring Security para a URL do emissor do provedor e escolha o módulo Spring que corresponde ao aplicativo: oauth2Login() para um aplicativo web renderizado no servidor, oauth2ResourceServer().jwt() para uma API REST que recebe tokens bearer e Spring Cloud Gateway com o filtro TokenRelay quando um gateway autentica usuários para um conjunto de microsserviços. Os usuários obtêm SSO porque todos os aplicativos os enviam para o mesmo Casdoor, que lembra a sessão: o segundo aplicativo redireciona, o Casdoor já conhece o usuário e eles retornam diretamente sem um formulário de login. Este post configura as três formas contra um único Casdoor, cada uma com um application.yml funcional e um SecurityFilterChain personalizado.

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.

Não existe "Steam OAuth": o Steam autentica usuários com OpenID 2.0 e fornece um SteamID de 64 bits, nada além disso. O Login Widget clássico do Telegram também não é OAuth: ele entrega à sua página um conjunto de campos de usuário mais um hash HMAC-SHA256 que você verifica com o token do seu bot. O Telegram agora também executa um provedor real de OpenID Connect em oauth.telegram.org. Se você colocar o Casdoor entre sua aplicação e esses provedores, o Casdoor faz as verificações específicas do protocolo e sua aplicação só conversa com o Casdoor usando OpenID Connect, da mesma forma que faria com Google ou GitHub.