Wir melden uns mit unserem eigenen SAML an unserer eigenen Admin-Konsole an. Das hat es gefangen.

Es gibt eine Variante von Dogfooding, die nur ein Slogan ist, und eine, bei der die eigenen Mitarbeiter keinen Code ausliefern können, bis der Fehler behoben ist. Wir leben die zweite. Die Authagonal-Mitarbeiterkonsole, mit der wir jeden Tenant verwalten, authentifiziert sich über Authagonal selbst: SAML Single Sign-on aus unserem Entra-Verzeichnis, wobei SCIM entscheidet, wer hereinkommt und was er tun darf. Es gibt keine separate Tabelle mit Admin-Passwörtern. Wir haben sie gelöscht. Wenn unser eigenes SAML kaputt ist, sind wir aus unserem eigenen Produkt ausgesperrt.

Das ist genau auf die nützliche Weise unbequem. Es macht aus "SSO ist eine Enterprise-Funktion, die wir unterstützen" ein "SSO ist die einzige Art, wie die Leute, die das gebaut haben, heute arbeiten können." Hier ist, was es gefangen hat, als wir unser eigener Kunde wurden.

Ein getrimmter Build, der die Signaturprüfung zerstörte

Wir veröffentlichen den Auth-Server getrimmt, um das Image klein zu halten. Trimming löscht aggressiv Code, dessen Nutzung es nicht beweisen kann, und Reflection verbirgt diese Nutzung vor ihm. .NET löst seine XML-Signatur-Krypto-Algorithmen über den Namen auf, reflektiv, über CryptoConfig. Der Trimmer konnte nicht erkennen, dass diese Typen benötigt wurden, entfernte sie, und SignedXml war plötzlich stillschweigend nicht mehr in der Lage, den Algorithmus aufzubauen. Die SAML-Signaturprüfung, der Schritt, der beweist, dass die Anmeldung echt ist, warf zur Laufzeit eine Null-Referenz.

Die Unit-Tests liefen durch, weil sie gegen den nicht getrimmten Build liefen, in dem die Typen noch existierten. Nur das getrimmte Produktionsartefakt scheiterte, und es scheiterte genau in dem Moment, in dem ein Mensch versuchte, sich anzumelden. Wir liefern den Auth-Server jetzt ungetrimmt aus, mit einem gesunden Misstrauen gegenüber dem Trimmen von allem in der Nähe reflektionsbasierter Krypto. Wenn wir SAML nur unterstützen würden, statt davon zu leben, wäre das ein Incident-Report eines Kunden statt unserer.

Provisioning ist der eigentliche Login

Einen Benutzer zu authentifizieren ist die einfache Hälfte von SSO. Die schwierige Hälfte ist, zu entscheiden, was er tun darf, und das synchron zu halten, während Leute kommen und gehen. Das steuern wir mit SCIM: Die Entra-Gruppenmitgliedschaft wird auf Rollen abgebildet, aufgelöst genau in dem Moment, in dem ein Token ausgestellt wird, nicht einmalig bei der Kontoerstellung kopiert. Fügen Sie jemanden zur richtigen Gruppe hinzu, und er hat bei seiner nächsten Anmeldung Zugriff; entfernen Sie ihn, und der Zugriff ist weg. Unsere eigene Zugriffsliste betreibt Dogfooding mit genau dem Gruppen-zu-Rollen-Mapping, das wir ausliefern.

Diese Verdrahtung bringt eine Klasse von Fehlern ans Licht, die nur existiert, wenn Authentifizierung und Autorisierung in zwei verschiedenen Systemen leben: Ein gerade provisionierter Admin konnte sich authentifizieren, bevor seine Rolle vollständig angekommen war, was die erste Anmeldung in einem gültigen, aber nicht autorisierten Zustand zurückließ. Die Lösung liegt in der Reihenfolge des Provisioning, nicht im Login, und man findet sie nur, indem man der neue Admin ist, der sich zum ersten Mal anmeldet.

Ein 500er, der ein 403er hätte sein sollen

Der kleinste Fehler war der peinlichste. Wenn ein authentifizierter Benutzer auf etwas stieß, das ihm nicht erlaubt war, gab die API einen 500er statt eines sauberen 403ers zurück, weil der Code-Pfad, der die "Forbidden"-Antwort ausstellt, von einem Dienst abhing, der in diesem Host nicht verdrahtet war. Eine abgelehnte Anfrage soll ein ruhiges, erwartetes Ergebnis sein, kein Serverfehler. Unsichtbar, bis man selbst derjenige ist, der abgelehnt wird.

Die Grenze, die uns am meisten am Herzen liegt

Unter all dem liegt die eine Regel, die eine mandantenfähige Identitätsplattform nicht falsch machen darf: Ein Tenant darf niemals zu unserem Admin werden. Wir vertrauen keiner einzelnen Prüfung. Die Plattform ist ihr eigener Issuer, und ein Tenant kann ihren Slug nicht beanspruchen; der Signaturschlüssel der Plattform ist von dem jedes Tenants getrennt, sodass ein für einen Tenant signiertes Token nicht als Plattform-Token wiederverwendet werden kann; und der Plattform-Store erzwingt Plattform-Rollen unabhängig. Drei Schlösser, weil die Kosten dafür, dass eines davon offen versagt, das gesamte Produkt sind.

Der Punkt

Keiner dieser Fehler wurde von einem cleveren Test gefangen. Sie wurden von einem Menschen gefangen, der versuchte, seine Arbeit zu erledigen, und es nicht konnte. Das ist das Argument dafür, das eigene Produkt in der Tiefe zu nutzen, in der es einem wehtun kann: Es verwandelt die Fehler, die sich in den Lücken zwischen den Systemen verstecken, in Fehler, die man vor dem Frühstück behebt, weil man nicht ausliefern kann, bevor man es tut.

Alles, worauf sich unsere Konsole stützt (SSO, SAML, SCIM, MFA, Audit-Logs), ist in jedem Authagonal-Tarif enthalten, nicht hinter einer Stufe gesperrt oder pro Verbindung abgerechnet. Sehen Sie, was enthalten ist.