Passer au contenu principal

Authentification multifacteur RADIUS pour VPN et Wi-Fi : TOTP 2FA avec le serveur RADIUS Casdoor

· Lecture de 12 minutes
Yang Luo
Casdoor Maintainer

Pour placer l'authentification multifacteur devant un VPN avec RADIUS, la passerelle VPN envoie le nom d'utilisateur et le mot de passe au serveur RADIUS via PAP, le serveur vérifie le mot de passe et répond avec un Access-Challenge, le client affiche une invite, et l'utilisateur saisit le code 2FA d'une application d'authentificateur dans une seconde requête. Casdoor fournit un serveur RADIUS qui fait exactement cela pour les utilisateurs ayant configuré TOTP, afin qu'une passerelle capable d'afficher une invite Access-Challenge (FortiGate SSL VPN est celle dont le fournisseur documente cette fonctionnalité) obtienne un mot de passe plus un code 2FA sans logiciel supplémentaire. Le Wi-Fi avec WPA2/WPA3-Enterprise est différent : 802.1X s'exécute sur EAP, qui n'a pas de place pour un code saisi, donc Casdoor dispose d'une option pour ignorer le code pour ces clients.

SSO Spring Boot avec OpenID Connect : Spring Security, Resource Server et Spring Cloud Gateway avec Casdoor

· Lecture de 13 minutes
Yang Luo
Casdoor Maintainer

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é.

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

· Lecture de 10 minutes
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.

OAuth Steam et OAuth Telegram avec Casdoor : Ajouter des connexions sociales non standards via OIDC

· Lecture de 11 minutes
Yang Luo
Casdoor Maintainer

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.

Passerelle de paiement fictive pour les tests : Fournisseur Dummy de Casdoor, Mode test Stripe et Bac à sable PayPal

· Lecture de 11 minutes
Yang Luo
Casdoor Maintainer

Une passerelle de paiement fictive est un fournisseur de paiement qui accepte tous les paiements comme payés sans contacter une banque ou un réseau de cartes, afin que vous puissiez tester les commandes, les abonnements et le traitement des commandes sans argent ni compte de passerelle. Casdoor en inclut un : le Fournisseur de paiement Dummy. Ajoutez-le à un produit, achetez le produit, et Casdoor enregistre le paiement et la commande comme Paid, démarre l'abonnement et écrit la transaction, le tout sans quitter votre serveur. Utilisez Dummy en développement, et passez à un bac à sable fournisseur (mode test Stripe, bac à sable PayPal, bac à sable Paddle) en préproduction, où vous avez également besoin de cartes refusées, de 3-D Secure et de redirections réelles.

Casdoor v4 : une nouvelle console, un Marketplace et OAuth pour les serveurs MCP

· Lecture de 6 minutes
Yang Luo
Casdoor Maintainer

Casdoor v4.0 est sorti le 1er septembre. Deux mois et 25 versions plus tard, nous en sommes à la v4.25 ; c'est donc le bon moment pour revenir sur ce qui a changé. En résumé : la console d'administration a été reconstruite, l'auto-hébergement est devenu beaucoup moins fastidieux, il existe désormais un Marketplace pour les intégrations et les thèmes de connexion, et Casdoor peut agir comme serveur d'autorisation pour les serveurs MCP et les agents IA.

Si vous ne l'avez jamais utilisé : Casdoor est une plateforme open-source de gestion des identités et des accès (IAM) écrite en Go. C'est un fournisseur d'identité complet, pas une bibliothèque ni un proxy de connexion. Les utilisateurs résident dans Casdoor, Casdoor émet les jetons, et vos applications communiquent avec lui via OAuth 2.0, OpenID Connect, SAML 2.0, CAS, LDAP ou SCIM. L'autorisation est gérée par Apache Casbin, de sorte que les modèles ACL, RBAC et ABAC fonctionnent tous. Il est sous licence Apache-2.0 et figure dans le CNCF Landscape.

Exécution de Casdoor sur Kubernetes : Helm Chart officiel et Configuration as Code

· Lecture de 6 minutes
Yang Luo
Casdoor Maintainer

Casdoor dispose d'un Helm chart officiel. Il se trouve dans le dépôt principal sous manifests/casdoor, est publié avec chaque version de Casdoor sur GHCR, et est référencé sur Artifact Hub. À partir de Casdoor v4.18.0, le chart peut également contenir vos organisations, applications, utilisateurs et fournisseurs comme configuration déclarative : modifiez-les dans le fichier values, exécutez helm upgrade, et les pods en cours appliquent la modification sans redémarrage.

Cet article détaille un déploiement Kubernetes depuis le premier helm install jusqu'à une configuration que vous pouvez conserver dans Git.

Casdoor rejoint le CNCF Cloud Native Landscape

· Lecture de 3 minutes
Yang Luo
Casdoor Maintainer

Le 22 février 2026, Casdoor a rejoint le CNCF Cloud Native Landscape, dans la catégorie Security & Compliance sous Provisioning. Le Landscape regroupe des projets et produits cloud-natifs largement utilisés ; son inclusion aide les utilisateurs et les entreprises à découvrir et évaluer des solutions pour construire des systèmes cloud-natifs.

https://landscape.cncf.io/?item=provisioning--security-compliance--casdoor

Amélioration de la sécurité des applications et de l'expérience utilisateur avec l'authentification faciale SSO de Casdoor

· Lecture de 3 minutes
James Lawson
Product Manager

À une époque où la gestion de l'identité numérique est cruciale, les solutions de Single Sign-On (SSO) comme Casdoor révolutionnent la manière dont les utilisateurs interagissent avec plusieurs applications. Le SSO de Casdoor simplifie le processus de connexion en permettant aux utilisateurs de s'authentifier une seule fois pour accéder à plusieurs services. Cela améliore non seulement la commodité pour l'utilisateur, mais augmente également l'engagement et la satisfaction.