Casdoor: Identity-Provider zum Selbsthosten mit MCP-Gateway

Ein Verzeichnis statt sechs Integrationspunkte

Das Problem, das Casdoor adressiert, ist die Vervielfachung von Konten. Sobald eine Organisation eine Single-Page-App, eine ältere Anwendung mit CAS-Anbindung und ein internes Werkzeug mit LDAP-Abfragen nebeneinander betreibt, entstehen drei Wahrheiten darüber, wer zu welcher Gruppe gehört. Casdoor setzt dagegen ein einziges Nutzerverzeichnis und stellt es über mehrere Protokolle bereit. Die README formuliert das so, dass dasselbe Verzeichnis über OAuth 2.0, OIDC, SAML 2.0, CAS, LDAP und SCIM erreichbar ist, damit eine moderne SPA und eine CAS-only-Anwendung einen gemeinsamen Kontobestand teilen können. Adressat sind damit nicht Endnutzer, sondern Plattform- und Backend-Teams, die Identität als eigene Infrastruktur betreiben wollen. Die README zieht die Grenze selbst: Wenn nur ein Login-Bildschirm vor einen vorhandenen Reverse Proxy gebraucht wird, passt ein kleineres Werkzeug besser. Casdoor ist für den Fall gedacht, dass man das Verzeichnis besitzt.

Go-Binary, Datenbank, Casbin-Regeln

Architektonisch beschreibt die README Casdoor als einzelnes Go-Binary plus Datenbank, ohne JVM, ohne Operator, ohne Clusterzwang. Das ist die zentrale Betriebsentscheidung: Es gibt keine verteilte Kontrollschicht, die man mitbetreiben müsste. Die Autorisierung liegt nicht in einem festen Rollenschema, sondern in Casbin-Modellen. Die README nennt ACL, RBAC, ABAC und eigene Modelle als Ausdrucksformen. Das ist ein Unterschied zu Systemen, in denen Rollen und Berechtigungen als feste Tabellenstruktur vorgegeben sind: Wer ein ungewöhnliches Regelwerk braucht, schreibt es als Casbin-Modell, statt sich an ein vorgegebenes Schema anzupassen. Der Preis dafür ist, dass die Regeln nicht mehr selbsterklärend aus der Oberfläche ablesbar sind. Wer Casbin-Modelle nicht kennt, muss sich mit der Modellsyntax befassen, bevor er Berechtigungen sauber strukturieren kann. Alles andere, also Organisationen, Anwendungen, Provider, Anmeldemethoden, E-Mail- und SMS-Vorlagen sowie das Branding der Anmeldeseite, liegt laut README in der Web-Konsole und nicht in Dateien, die ein Redeploy erfordern.

Vom Container zur eigenen Instanz

Der schnellste Weg ist ein einzelner Befehl: docker run -p 8000:8000 casbin/casdoor-all-in-one. Danach ist die Instanz unter http://localhost:8000 erreichbar, die Anmeldung erfolgt mit der Organisation built-in, dem Benutzernamen admin und dem Passwort 123. Die README weist ausdrücklich darauf hin, dass das Anmeldeformular getrennte Felder für Organisation und Benutzername hat und die Schreibweise built-in/admin in der Dokumentation dasselbe meint. Dieses Image bündelt SQLite und Beispieldaten und ist ausdrücklich nicht für den Produktivbetrieb gedacht, weil die Daten im Container liegen und mit ihm verschwinden. Für den dauerhaften Betrieb nennt die README eine docker-compose.yml, die Casdoor neben einem MySQL-8-Container startet. Zwei Punkte sind dort vorab zu beachten. Erstens baut Compose das Image aus dem Quellcode, also Go-Backend plus React-Frontend, weshalb der erste docker compose up mehrere Minuten dauert und nicht als Schnelltest taugt. Zweitens muss Casdoor zuerst auf die mitgelieferte Datenbank zeigen; die README verlangt hier eine Anpassung der MySQL-Verbindung vor dem Start. Der Konfigurationsabschnitt der README ist an dieser Stelle abgeschnitten, die konkreten Schlüsselnamen für die Datenbankverbindung lassen sich aus dem vorliegenden Material nicht belegen.

MCP und Agent-Gateway: was die Materiallage hergibt

Die Projektbeschreibung führt Casdoor als Agent-first IAM und als LLM MCP and agent gateway and auth server, und MCP taucht sowohl in der Themenliste als auch in der Protokollaufzählung der README auf. Das ist der Teil, der Casdoor von klassischen Identity-Providern abhebt: Ein Agent, der ein MCP-Server-Werkzeug aufruft, braucht eine Autorisierungsentscheidung, und Casdoor positioniert sich als die Instanz, die diese Entscheidung trifft. Belastbar belegen lässt sich aus dem vorliegenden Material allerdings nur, dass MCP als unterstütztes Protokoll genannt wird. Wie die MCP-Anbindung konkret aussieht, welche Endpunkte entstehen, ob ein Agent als eigener Prinzipal im Verzeichnis geführt wird und wie Token für Agenten geschnitten sind, geht aus der README nicht hervor. Wer Casdoor genau wegen dieses Punktes evaluiert, sollte die Dokumentation unter casdoor.ai/docs/overview heranziehen, bevor er Architekturentscheidungen darauf stützt. Die Protokollliste allein ist kein Nachweis dafür, dass die Agenten-Seite denselben Reifegrad hat wie die klassischen SSO-Pfade.

Zwei Demos mit sehr unterschiedlichem Charakter

Die README bietet zwei gehostete Instanzen an, die sich in einem Punkt grundlegend unterscheiden. demo.casdoor.com ist beschreibbar, erlaubt vollen Zugriff und setzt die Daten etwa alle fünf Minuten zurück. door.casdoor.net ist der stabile globale Demo-Zugang, bei dem laut README jede Schreiboperation bewusst fehlschlägt. Beide akzeptieren dieselben Zugangsdaten built-in, admin und 123. Für die Evaluierung ist das eine brauchbare Aufteilung: Auf der beschreibbaren Instanz lassen sich Anwendungen, Provider und Anmeldemethoden durchklicken, ohne eine eigene Umgebung aufzusetzen. Wer dagegen wissen will, wie sich die Oberfläche unter stabilen Bedingungen verhält, nutzt die schreibgeschützte Variante und muss akzeptieren, dass dort nichts gespeichert wird. Der Fünf-Minuten-Reset ist kein Nebendetail, sondern bestimmt, was man auf der beschreibbaren Demo sinnvoll testen kann: Ein mehrstufiger Aufbau, bei dem man zwischendurch einen Provider konfiguriert, kann mitten im Ablauf verschwinden.

Wo Casdoor das falsche Werkzeug ist

Die erste Einschränkung steht in der README selbst, und sie ist keine Formalie: Das All-in-One-Image ist ein Evaluierungswerkzeug. Daten im Container bedeuten, dass ein Neuaufsetzen des Containers die Identitäten mitnimmt. Wer diesen Weg produktiv nutzt, verliert das Verzeichnis bei der ersten Image-Aktualisierung. Die zweite Einschränkung betrifft die Konfiguration als Ganzes. Dass Organisationen, Anwendungen, Provider und Branding in der Datenbank und nicht in versionierten Dateien liegen, ist für den Einstieg bequem, für den Betrieb aber eine Umstellung. Änderungen an der Anmeldeseite oder an Provider-Toggles sind damit nicht im selben Review-Prozess wie Code, und Umgebungen wie Staging und Produktion lassen sich nicht durch einen anderen Config-Satz auseinanderhalten. Ob Casdoor dafür einen Export- oder Importpfad anbietet, ist aus dem vorliegenden Material nicht ersichtlich. Drittens ist Casdoor kein Proxy und keine Bibliothek. Die README grenzt beides ausdrücklich ab. Wer Identität nur durchreichen will und das Verzeichnis woanders führt, baut mit Casdoor eine zweite Quelle auf, die er nicht braucht.

Alternative Keycloak und der Unterschied im Ansatz

Die naheliegende Alternative ist Keycloak. Beide sind selbstgehostete Identity-Provider mit Admin-Konsole und Unterstützung für OAuth 2.0, OIDC und SAML, und beide bringen eigene Autorisierungskonzepte mit. Der Unterschied liegt in den Betriebsvoraussetzungen und in der Autorisierung. Keycloak ist eine Java-Anwendung, die üblicherweise mit einer JVM und in größeren Setups mit einer Operator- oder Cluster-Topologie betrieben wird. Casdoor beschreibt sich dagegen als ein einzelnes Go-Binary plus Datenbank, ohne JVM und ohne Clusterzwang. Für ein Team, das bereits Java-Infrastruktur betreibt, ist das kein Vorteil, sondern nur ein weiterer Stack. Für ein Team ohne JVM-Erfahrung ist es der entscheidende Punkt. Bei der Autorisierung geht Keycloak den Weg fester Rollen- und Ressourcenkonzepte in der Oberfläche, Casdoor den Weg über Casbin-Modelle. Das ist ein Trade-off zwischen Selbsterklärung und Ausdrucksstärke: In Keycloak ist eine Berechtigung meist direkt in der Konsole nachvollziehbar, in Casdoor steht sie im Modell. Wer CAS oder LDAP als Protokolle braucht, findet in Casdoor beides in derselben Aufzählung wie OAuth und SAML, was die Migration gemischter Anwendungslandschaften vereinfacht.

Wartung, Releases und Lizenz

Die Release-Historie im vorliegenden Material zeigt v4.1.0, v4.2.0 und v4.3.0 mit Abständen von wenigen Tagen, jeweils im September 2026. Kurze Abstände zwischen Minor-Versionen bedeuten, dass ein Upgrade-Pfad eingeplant werden muss, und dass man vor dem Sprung auf eine neue Minor-Version prüfen sollte, ob die eigene Konfiguration davon berührt wird. Da die Anwendungskonfiguration laut README in der Datenbank liegt, ist das Datenbankschema der kritische Teil eines Upgrades, nicht nur das Binary. Ein Rollback auf die vorherige Version ist ohne Sicherung des Datenbestands nicht verlässlich möglich. Als Aufwandsposten kommen damit zusammen: das Betreiben der Datenbank, die Pflege der Casbin-Modelle und die Frage, wie Konfigurationsänderungen zwischen Umgebungen übertragen werden. Zur Lizenz: Casdoor steht unter Apache-2.0, einer permissiven Lizenz, die kommerzielle Nutzung und Änderungen erlaubt und keine Copyleft-Pflichten für abgeleitete Werke auslöst. Die Lizenzangabe im Repository ist die Quelle; für die eigene Rechtslage ist sie kein Ersatz für eine Prüfung, und Marken- oder Namensrechte sind davon ohnehin nicht erfasst.

Redaktionelles Fazit

Casdoor passt zu Teams, die das Nutzerverzeichnis selbst betreiben wollen und mehrere Protokolle aus einer Datenbasis bedienen müssen, etwa eine moderne SPA neben einer Anwendung, die nur CAS spricht. Wer lediglich ein Login-Formular vor einen bestehenden Reverse Proxy setzen will, fährt mit einem kleineren Werkzeug günstiger, und für reine Bibliotheks-Einbettung ist Casdoor ohnehin nicht gedacht. Vor dem Produktivgang zu klären: ob die im Compose-Setup nötige Anpassung der MySQL-Verbindung im eigenen Deployment sauber abgebildet ist, wie das Datenverzeichnis gesichert wird und ob die Konfiguration der Anwendungen, Provider und Brandings im UI versioniert oder exportiert wird. Ohne diesen Export lebt ein Teil der Identitätskonfiguration nur in der Datenbank.

Offizielle Quellen

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