Identix: Plattform für Identitäts- und Zugriffsmanagement

Identix ist ein Identitätsanbieter für den Eigenbetrieb. Ein Unternehmen installiert ihn in der eigenen Infrastruktur, und eine einzige Installation bedient viele voneinander unabhängige Anwendungen (Mandanten) – jede mit eigenen Benutzern, Rollen, Anmeldeeinstellungen und Signaturschlüsseln. Passwörter, Schlüssel und personenbezogene Daten verlassen nie die Infrastruktur des Betreibers.

Die Identitätsverwaltung ist der sicherheitskritischste Teil jedes Systems: Ein Fehler an dieser Stelle gefährdet alle Anwendungen, die darauf aufbauen. Das Projekt musste daher einen großen Funktionsumfang mit einer Sicherheitsarchitektur verbinden, die einer kritischen Prüfung standhält. Ein einziger Ingenieur hat es entworfen und gebaut und betreut es bis heute.

Autorisierungsserver – OAuth 2.0 und OpenID Connect auf Basis von Spring Authorization Server, mit eigenem Aussteller und eigenen Signaturschlüsseln für jeden Mandanten, Rotation der Refresh-Tokens und sofortigem Widerruf von Tokens.

• Strikte Mandantentrennung – jede Anfrage bleibt auf ihren Mandanten beschränkt; automatisierte Architekturtests setzen diese Regel durch
• Benutzer, Rollen, Gruppen und Organisationen mit Massenimport und -export sowie einer Passwortrichtlinie je Mandant
• Zwei-Faktor-Authentifizierung (TOTP) mit Wiederherstellungscodes
• Protokollierter Identitätswechsel – ein Administrator kann im Namen eines Benutzers handeln; jede solche Sitzung wird aufgezeichnet
• Webhooks mit HMAC-Signatur für Ereignisse im Lebenszyklus von Benutzern
• Prüfprotokoll – je Mandant geführt, Einträge werden ausschließlich angefügt; für den Betreiber gibt es eine mandantenübergreifende Ansicht
• Export und Import der Mandantenkonfiguration zwischen Installationen

Verwaltungskonsole – React und TypeScript, auf Englisch und Russisch, für Bildschirme vom Desktop bis zum Smartphone ausgelegt, mit integriertem Entwicklerbereich: Integrationsleitfäden und interaktive API-Dokumentation.

Öffentliche API – 237 Operationen, vollständig in OpenAPI beschrieben.

Infrastruktur – drei Services auf Kubernetes mit Helm-Charts, PostgreSQL und Redis sowie drei CI/CD-Pipelines in GitLab, die jeden Service bauen, testen und bereitstellen. Schlägt auch nur ein Test fehl, wird die Bereitstellung blockiert.

Die Architektur trennt Vertrauenszonen. Der öffentliche Autorisierungsserver hat keinen Zugriff auf die Datenbank und verwahrt keine privaten Schlüssel: Sämtliche Daten und das Signieren aller Tokens liegen bei einem internen Service, der nur innerhalb des Clusters erreichbar ist. Signaturschlüssel werden verschlüsselt gespeichert und nur im Arbeitsspeicher entschlüsselt; wird der öffentliche Knoten kompromittiert, gibt er daher weder Schlüssel noch Daten preis.

Sicherheit war Teil der Methode, kein nachträglicher Zusatz:

• Bedrohungsmodell nach STRIDE: schützenswerte Werte, Angreiferprofile, Vertrauensgrenzen und eine Gegenmaßnahme für jede Bedrohung
• Sicherheitsdokumentation für Prüfer mit Zuordnung der Sicherheitsmaßnahmen zu OWASP ASVS Level 2 und zu den bewährten Verfahren der IETF für OAuth 2.0 und JWT
• Sicherheitsaudit erfolgreich abgeschlossen; alle Feststellungen wurden behoben

Ein Ingenieur in der Rolle des Architekten und KI-Orchestrators, nach der Methode Specification-Driven Development. Am Anfang stand eine schriftliche Spezifikation (Anforderungen, Datenmodell, Sicherheitsinvarianten); jede wesentliche Entscheidung wurde vor der Implementierung als Architekturentscheidung (ADR) dokumentiert.

KI-Agenten erzeugten auf Grundlage dieser Spezifikation Code, Tests und Dokumentation; der Ingenieur prüfte jede Änderung, verantwortete Architektur und Sicherheitsmodell und stand für jeden Commit ein. Die Infrastruktur (Kubernetes-Manifeste, Helm-Charts, CI/CD-Pipelines) entstand durch dieselbe Person auf dieselbe Weise.

Die Entwicklung verlief nicht durchgehend: Das Projekt schritt in Etappen voran, mit Pausen dazwischen. Zählt man nur die Tage, an denen tatsächlich gearbeitet wurde, entstand die Plattform in 40 Arbeitstagen.

Identitäts- und Zugriffsmanagement ist kein naheliegendes Beispiel für schnelle Auslieferung: Es verbindet einen großen Funktionsumfang mit kompromisslosen Sicherheitsanforderungen. Identix zeigt, dass die Methode auch hier trägt.

Ein Ingenieur. 40 Arbeitstage. Ein mandantenfähiger Autorisierungsserver, eine Verwaltungskonsole, eine öffentliche API mit 237 Operationen, rund 1.700 automatisierte Tests, Kubernetes und CI/CD sowie eine Sicherheitsarchitektur, die sich auf ein Bedrohungsmodell und ein abgeschlossenes Audit stützt.

Entscheidend war nicht die Geschwindigkeit der Codegenerierung, sondern die Disziplin, die sie umgibt: zuerst die Spezifikation, Entscheidungen dokumentiert, jede Änderung geprüft. Das macht das System wartbar – und genau das würde es einem anderen Team ermöglichen, es zu übernehmen.