Casdoor : porter l'annuaire d'identités plutôt que de le déléguer

Le répertoire, pas la façade

Beaucoup d'outils se présentent comme des solutions d'authentification alors qu'ils se contentent de poser une couche devant un annuaire existant. Le README de Casdoor prend le contre-pied et le dit sans détour : le projet se décrit comme un fournisseur d'identité complet, et non comme un proxy d'authentification ni comme une bibliothèque à intégrer. La différence est concrète. Casdoor stocke les utilisateurs, émet les jetons et expose une console d'administration pour gérer l'ensemble. Vos applications délèguent la connexion et ne manipulent jamais un mot de passe.

Le public visé découle de ce choix. Une organisation qui doit faire cohabiter une application monopage récente et un logiciel ancien qui ne parle que CAS a besoin d'un point unique où vivent les comptes. Le README donne exactement cet exemple : le même annuaire est accessible via OAuth 2.0, OIDC, SAML 2.0, CAS, LDAP et SCIM 2.0, ce qui permet à des applications de générations différentes de partager un seul jeu d'identifiants. Si vous n'avez qu'un seul service à protéger et aucun besoin de fédérer, l'argument tombe.

Un point de vocabulaire qui fait perdre du temps : le formulaire de connexion sépare l'organisation et le nom d'utilisateur. La documentation écrit parfois la paire sous la forme built-in/admin, ce qui n'est pas un identifiant contenant une barre oblique mais deux champs distincts.

Ce que la console remplace

Le mécanisme central du projet est un serveur Go unique accompagné d'une base de données. Le README insiste sur l'absence de JVM, d'opérateur Kubernetes et de cluster obligatoire. C'est un argument de déploiement, pas de performance : il signifie qu'une seule équipe peut installer et faire tourner l'ensemble sans compétence particulière en orchestration.

La partie qui distingue vraiment Casdoor de ses concurrents se situe dans la console. Organisations, applications, fournisseurs d'identité, méthodes de connexion, modèles d'e-mails et de SMS, image de marque de la page de connexion : tout se configure dans l'interface web plutôt que dans des fichiers qu'il faut redéployer. Le README illustre ce point avec l'onglet Providers d'une application, où chaque fournisseur dispose de bascules d'inscription, de connexion et de dissociation. Pour une équipe qui doit activer un fournisseur social un vendredi après-midi, la différence avec un fichier de configuration versionné est tangible.

L'autorisation repose sur Casbin, avec des modèles ACL, RBAC, ABAC ou personnalisés. Le projet ne propose donc pas un schéma de permissions figé. C'est plus souple, et cela déplace le travail : la politique d'accès devient un artefact que quelqu'un doit écrire et maintenir, pas une case à cocher.

Démarrer sans base de données, puis changer d'avis

Le chemin le plus court tient en une commande, sans fichier de configuration ni base de données externe :

docker run -p 8000:8000 casbin/casdoor-all-in-one

L'instance écoute sur le port 8000 avec SQLite et des données d'exemple. Les identifiants du README sont l'organisation built-in, l'utilisateur admin et le mot de passe 123. Le README est explicite sur la suite : cette image n'est pas destinée à la production, car les données vivent à l'intérieur du conteneur et disparaissent avec lui.

Le second chemin utilise le fichier docker-compose.yml du dépôt, qui démarre Casdoor à côté d'un conteneur MySQL 8. Deux avertissements accompagnent cette procédure, et ils comptent. D'abord, Compose construit l'image depuis les sources, backend Go et frontend React compris : le premier docker compose up prend plusieurs minutes, ce qui en fait un mauvais choix pour un essai rapide. Ensuite, il faut pointer Casdoor vers la base embarquée avant de lancer quoi que ce soit. Le README commence à décrire cette étape avec la clé de configuration MySQL mais le texte fourni s'interrompt là. Je ne peux donc pas donner le nom exact du paramètre. Vérifiez-le dans le guide de déploiement du dépôt avant de reproduire une commande trouvée ailleurs.

Pour un essai sans installation, deux démos publiques existent. demo.casdoor.com est accessible en écriture et réinitialise ses données environ toutes les cinq minutes. door.casdoor.net est stable mais refuse toute écriture par conception. Les deux acceptent les mêmes identifiants built-in / admin / 123.

Le piège du conteneur all-in-one

La limite la plus mal comprise du projet n'est pas technique, elle est documentaire. L'image casbin/casdoor-all-in-one est mise en avant comme le moyen d'essayer en trente secondes, et elle remplit parfaitement ce rôle. Le README précise aussi, en gras, qu'elle n'est pas prévue pour la production parce que les données disparaissent avec le conteneur. Entre la promesse de rapidité et cet avertissement, il y a une pente sur laquelle des équipes glissent : l'instance d'évaluation devient l'instance de recette, puis celle de production, et le jour où le conteneur est recréé, les comptes partent avec lui.

Un deuxième cas où Casdoor est le mauvais outil est énoncé par le projet lui-même. Si tout ce dont vous avez besoin est un écran de connexion devant un reverse proxy existant, un outil plus petit conviendra mieux. Casdoor s'adresse à qui veut posséder l'annuaire, avec ce que cela implique : sauvegardes, migrations de schéma, montées de version.

Il faut ajouter une réserve sur le rythme de publication. Trois versions sont listées entre le 2 et le 9 septembre 2026, soit v4.1.0, v4.2.0 et v4.3.0. Le matériel fourni ne dit rien de leur contenu, donc je ne peux pas juger s'il s'agit de correctifs ou de changements de schéma. Une cadence hebdomadaire n'est pas un défaut en soi, mais elle déplace la charge : quelqu'un doit lire les notes de version et décider quand monter, sinon l'instance prend du retard et la mise à jour suivante devient risquée.

Face à Keycloak, la différence est le modèle de configuration

L'alternative la plus directe est Keycloak, autre serveur d'identité auto-hébergé et open source, lui aussi écrit en Java et distribué sous Apache-2.0. Les deux couvrent OIDC, SAML, LDAP et la fédération vers des fournisseurs externes, donc choisir entre eux sur une liste de protocoles n'a pas de sens.

La divergence porte sur deux points que le README de Casdoor rend visibles. Le premier est le runtime : Casdoor est un binaire Go unique avec une base de données, sans JVM. Le second est la configuration. Casdoor place organisations, applications, fournisseurs, modèles d'e-mails et image de marque dans la console web, sans redéploiement. Keycloak, dans son usage courant, s'administre largement par fichiers de configuration et par import de royaumes, ce qui convient mieux à une équipe qui veut versionner son paramétrage d'identité dans Git et le rejouer à l'identique sur plusieurs environnements. Ce n'est pas une question de qualité mais de flux de travail : si votre modèle est l'infrastructure as code, l'approche de Casdoor vous demandera de construire vous-même la couche qui exporte et versionne ce que la console contient.

L'autre différence tient à l'autorisation. Casdoor s'appuie sur Casbin et laisse le modèle de politique ouvert. Keycloak fournit un modèle de rôles et de permissions plus cadré. Là encore, la flexibilité de Casdoor se paie en travail de conception.

Maintenance, mises à jour et licence

Le coût d'exploitation se répartit en trois postes identifiables à partir du dépôt. Le premier est la base de données : SQLite suffit pour évaluer, MySQL 8 est le choix montré par le fichier docker-compose.yml, et c'est cette base qu'il faudra sauvegarder et faire évoluer. Le deuxième est la chaîne de compilation si vous passez par Compose, puisque l'image est construite depuis les sources Go et React : prévoyez du temps de build à chaque montée de version, ou construisez votre propre image. Le troisième est la cadence de publication, avec trois versions en une semaine sur la période couverte par le matériel.

Sur la licence, Casdoor est distribué sous Apache-2.0. Cette licence est permissive : usage commercial, modification et redistribution sont autorisés, avec conservation des mentions de copyright et du texte de licence, et elle comporte une clause de brevets. Je ne donne pas de conseil juridique. Si vous redistribuez Casdoor modifié dans un produit, faites relire les obligations de mention par qui de droit dans votre organisation.

Un point que le matériel ne permet pas de trancher : la procédure de migration de schéma entre versions majeures. Le README s'interrompt avant d'avoir décrit la configuration MySQL complète, et les notes de version ne sont pas fournies. C'est précisément ce qu'il faut vérifier en premier si vous partez d'une version ancienne, parce qu'un annuaire d'identités qui ne migre pas proprement n'a pas de plan B simple.

Conclusion éditoriale

Casdoor convient aux équipes qui veulent posséder leur répertoire d'utilisateurs et servir plusieurs générations d'applications avec un seul jeu de comptes. Il ne convient pas si vous cherchez seulement un écran de connexion devant un reverse proxy existant, ni si personne chez vous ne veut exploiter une base de données et des montées de version régulières. Avant de vous engager, vérifiez deux choses précises : que la pile de migration livrée avec la version que vous installez sait faire évoluer votre schéma depuis votre version actuelle, et que le mode de déploiement retenu persiste bien les données hors du conteneur.

Sources officielles

1. casdoor/casdoor on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases