Im Juni haben wir eine Identitätsschicht in die Anwendungen eingebaut, die OwlMeans generiert.
Sichtbar war davon der Anmeldebildschirm. Dahinter lagen Konten, Sitzungen und Berechtigungen, außerdem die Trennung zwischen den Menschen, die unsere Plattform nutzen, und denen, die eine Kunden-App nutzen. Ich wollte, dass diese Entscheidungen von Anfang an zur Architektur der Anwendung gehören.
Konten und Anmeldung
Ein erfolgreicher Login verrät einer Anwendung, wer da ist. Was diese Person lesen oder ändern darf, ist damit noch nicht geklärt.
Eine Kundenorganisation braucht vielleicht eine Person, die ihre eigenen Datensätze sieht, eine zweite, die eine Warteschlange abarbeitet, und eine dritte, die Zugriffe verwaltet. Das sind unterschiedliche Verantwortlichkeiten, auch wenn die Bildschirme ähnlich aussehen.
Die Erklärung der OpenID Foundation zu OpenID Connect beschreibt das Identitätsprotokoll. Die Berechtigungen ergeben sich trotzdem aus den Geschäftsregeln der Anwendung.
Im Juni haben wir den Anmeldeablauf mit der generierten App verbunden und eine einheitliche Art geschaffen, Zugriffsrechte abzubilden. Damit hatte der restliche Code eine konsistente Grundlage. Über die Regeln im einzelnen Kundenprojekt entscheidet die Kundschaft aber weiterhin selbst.
In dieser Implementierung meldeten sich die Nutzenden einer App mit einem Einmalcode per E-Mail an. So brauchte die generierte Anwendung keinen eigenen Ablauf für die Passwortverwaltung.
Die Anmeldung per E-Mail würde ich weder als allgemeine Sicherheitsgarantie bezeichnen noch mit jedem stärkeren Authentifizierungsverfahren gleichsetzen. Zustellweg, Kontowiederherstellung und Sitzungsverhalten wollen trotzdem durchdacht sein. Dasselbe gilt für die Frage, wie eine Person Mitglied einer Kundenorganisation wird. Solche Details übersieht man leicht, wenn man bei der Abnahme nur prüft, ob sich ein Login-Formular absenden lässt.
Zugriffsgrenzen
Das Berechtigungsmodell wollte ich aus verstreuten Ad-hoc-Entscheidungen heraushalten. Ein Bildschirm kann eine Zugriffsvoraussetzung haben. Die Operation dahinter braucht aber ebenfalls eine, und die muss auch durchgesetzt werden. Einen Button auszublenden, ist eben noch keine Autorisierungsregel.
Das Authorization Cheat Sheet von OWASP empfiehlt, Zugriffsgrenzen festzulegen, Zugriffe standardmäßig zu verweigern und Berechtigungen bei Anfragen zu prüfen. Außerdem verlangt es Tests für diese Regeln.
In unserer Anwendungsstruktur deklariert man die Voraussetzung über die Zugriffskonventionen des Frameworks. Die Geschäftslogik sollte diese Konventionen durchgängig nutzen, statt in jedem Handler eine eigene Auslegung zu erfinden.
Bei einem gewöhnlichen Arbeitswerkzeug würde ich die tatsächlichen Unterschiede testen: Wer die App ganz normal nutzt, darf den eigenen Datensatz ansehen. Wer die Warteschlange abarbeitet, darf eine zugewiesene Anfrage bearbeiten. Und keine der beiden Personen sollte Administrationsrechte bekommen, nur weil sie sich angemeldet hat.
Dieses Verhalten gehört in die Produktanforderungen und in die Tests. Ein Protokollname allein kann es nicht sicherstellen.
OwlMeans hat eigene Konten. Eine App, die damit entsteht, hat ihre eigene Nutzerschaft. Beides auseinanderzuhalten, gehörte zur Arbeit am Identitätsmanagement.
Grenzen zwischen Kundenorganisationen, Projekten und Ressourcen sind wichtig, weil eine Identität gültig sein kann, während eine bestimmte Aktion trotzdem außerhalb ihrer Befugnisse liegt. Eine Nutzer-ID allein reicht nicht aus, um all diese Grenzen auszudrücken.
Für den Produktivbetrieb braucht die App außerdem die Anmeldekonfiguration, die dafür vorgesehen ist. Dass Konten und Weiterleitungsadressen aus der Vorschau auch dort gelten, sollte man nicht einfach annehmen.
Praktisch zählt, ob die richtige Person den vorgesehenen Ablauf abschließen kann und ob jemand außerhalb dieser Grenze abgewiesen wird.
OIDC und Auslieferung
OIDC gibt der Anwendung eine standardisierte Schnittstelle für Identitäten. Damit ist aber nicht gesagt, dass jede Anbindung an die Identitätssysteme von Unternehmen verfügbar ist. Es heißt auch nicht, dass jede Mandantengrenze getestet oder der Sicherheitsfragebogen aus dem Einkauf beantwortet ist. Die frühere Fassung dieses Artikels ließ das zu sehr nach Automatik klingen.
Eine Integration hängt weiterhin vom Identitätsanbieter und von der Konfiguration ab. Die Rollen und Organisationsregeln der Kundschaft müssen nach wie vor spezifiziert werden. Die generierte Anwendung zu prüfen, bleibt Teil der Auslieferung. Ich beschreibe lieber die Bausteine, die wir haben, als eine Zertifizierung anzudeuten, nur weil wir uns für ein Protokoll entschieden haben.
Im August wurde das integrierte Identitätssystem zur einzigen IAM-Implementierung der Plattform. Die Überlegungen vom Juni zu einem austauschbaren externen Backend haben nur noch historischen Wert.
Bei der Arbeit an der Zugriffssteuerung unterscheiden wir heute außerdem zwischen umgesetzten Schutzmaßnahmen und Verfeinerungen, die noch in Entwicklung sind. Dokumentation und Code belegen den Mechanismus. Dass jede damit gebaute Anwendung sicher ist, können sie nicht beweisen.
Der aktuelle Leitfaden zur Authentifizierung erklärt die Bausteine des Frameworks. Das Zugriffskonzept einer Anwendung muss man an dem Produkt prüfen, das gerade entsteht.
Wenn wir Identität direkt einbauen, pflegen wir diesen Teil des Systems selbst. Die Kundschaft muss trotzdem beschreiben, welche Personen, Ressourcen und Aktionen ihr Produkt braucht. Wir haben eine einheitliche Art, diese Regeln auszudrücken. Sie zu prüfen, bleibt Teil der Arbeit.
Überarbeitet am 15. Oktober 2026. Die Geschichte der Implementierung vom Juni bleibt erhalten. Korrigiert sind die früheren Preisvergleiche und die pauschalen Versprechen zu Enterprise-Tauglichkeit und Sicherheit.