6 posts tagués avec "OIDC"

Chaque outil d'une stack DevOps auto-hébergée typique peut agir en tant que client OpenID Connect : Gitea et Argo CD prennent en charge nativement OIDC, Jenkins le fait via le plugin oic-auth, Grafana et Portainer via OAuth 2.0 générique, et MinIO, Harbor et GitLab via leurs paramètres OIDC. Pointez-les tous vers une seule instance Casdoor, attribuez à chaque outil sa propre application Casdoor, et placez vos utilisateurs dans des groupes Casdoor. Chaque outil lit alors la revendication groups et décide qui est administrateur. Cet article liste l'URL de callback, les clés de configuration et le mappage des groupes pour chaque outil, puis couvre les parties communes.

Nginx open-source ne dispose pas de module CAS, donc « authentification CAS pour nginx » signifie en pratique l'une des deux configurations suivantes. Soit nginx interroge un service d'authentification pour chaque requête via son module auth_request, et Casdoor répond (directement sur /api/forward-auth, ou via casdoor-forward-auth ou OAuth2 Proxy), soit l'application derrière nginx est elle-même un client CAS et communique avec les endpoints du serveur CAS de Casdoor. Si vous pouvez recompiler nginx, le module nginx de Casdoor exécute la connexion à l'intérieur de nginx, et si vous préférez ne pas utiliser nginx, le proxy de site de Casdoor peut se placer devant l'application. Dans tous les cas, la page de connexion est celle de Casdoor, de sorte qu'une seule session SSO, un seul jeu d'autorisations et une seule politique MFA couvrent toutes les applications.

Déconnecter un utilisateur d'une application OpenID Connect nécessite plus que la suppression de votre propre cookie de session. L'utilisateur est toujours connecté au fournisseur d'identité, donc le prochain clic sur "Sign in" passe directement sans mot de passe, et les autres applications partageant cette session du fournisseur d'identité restent également connectées. Une déconnexion correcte comprend trois parties : effacer la session locale de votre application, envoyer le navigateur vers l'end_session_endpoint du fournisseur (déconnexion initiée par le RP) pour mettre fin à la session du fournisseur, et permettre au fournisseur d'informer les autres applications via la déconnexion back-channel. Avec Casdoor, l'endpoint de fin de session est /api/logout, la déconnexion back-channel est configurée par application, et les jetons de rafraîchissement peuvent être révoqués via /api/login/oauth/revoke.

Pour ajouter l'authentification unique (SSO) à Spring Boot, enregistrez chaque application en tant qu'application dans un fournisseur OpenID Connect tel que Casdoor, pointez Spring Security vers l'URL d'émetteur du fournisseur, et choisissez le module Spring correspondant à l'application : oauth2Login() pour une application web rendue côté serveur, oauth2ResourceServer().jwt() pour une API REST qui reçoit des jetons bearer, et Spring Cloud Gateway avec le filtre TokenRelay lorsqu'une passerelle authentifie les utilisateurs pour un ensemble de microservices. Les utilisateurs bénéficient du SSO car toutes les applications les redirigent vers le même Casdoor, qui mémorise la session : la deuxième application effectue une redirection, Casdoor connaît déjà l'utilisateur, et celui-ci revient directement sans formulaire de connexion. Cet article met en place ces trois configurations contre un seul Casdoor, chacune avec un fichier application.yml fonctionnel et un SecurityFilterChain personnalisé.

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.

Il n'existe pas d'« OAuth Steam » : Steam authentifie les utilisateurs avec OpenID 2.0 et vous fournit un SteamID 64 bits, rien de plus. Le widget de connexion classique de Telegram n'est pas non plus de l'OAuth : il transmet à votre page un ensemble de champs utilisateur ainsi qu'un hash HMAC-SHA256 que vous vérifiez avec votre token de bot. Telegram propose désormais également un véritable fournisseur OpenID Connect sur oauth.telegram.org. Si vous placez Casdoor entre votre application et ces fournisseurs, Casdoor effectue les vérifications spécifiques au protocole et votre application ne parle que OpenID Connect à Casdoor, de la même manière que pour Google ou GitHub.