Abschätzung des Aufwands für eine SSO-Integration

Bei SSO geht es meist um die Eigenheiten anderer: Man muss zunächst den Identitätsanbieter einrichten, der Rest ist reine Routine.

„SSO hinzufügen“ klingt nach einer einzigen Funktion. Es sind jedoch zwei. Die erste ist ein kleiner Teil der OAuth-, SAML- oder OIDC-Infrastruktur: gut dokumentiert, es gibt Bibliotheken, und jede moderne Authentifizierungsbibliothek verfügt über ein Tutorial. Die zweite umfasst alles, was der Identitätsanbieter tut, was nicht im Tutorial enthalten ist: die Claim-Namen, die nicht der Spezifikation entsprechen, die Regeln für die Redirect-URI, die strenger sind als in der Spezifikation vorgesehen, das Session-Timeout, das nicht mit Ihrem übereinstimmt, der „Off-by-One“-Fehler bei der Serialisierung von Gruppen, der Metadaten-Endpunkt, der dienstags ungültiges XML zurückgibt. Der erste Teil ist die Geschichte, über die jeder abstimmen kann. Der zweite Teil sind die entscheidenden Punkte.

Das bedeutet, dass es bei der Einschätzung nicht wirklich um SSO geht. Es geht um diesen Identitätsanbieter und darum, ob jemand im Team bereits Erfahrung mit dessen Integration hat. Okta mit einer Standard-SAML-Konfiguration ist etwas ganz anderes als Azure AD mit einer benutzerdefinierten Anspruchsregel, die niemand auf beiden Seiten vollständig versteht. Ein Team, das eine Okta-Integration innerhalb eines Sprints fertigstellt, wird drei Sprints für eine föderierte AD FS-Bereitstellung mit einem benutzerdefinierten Proxy davor benötigen, und der Code, den es schreibt, sieht am Ende fast identisch aus.

Was in dem Raum gesagt wird

Backend: „Es handelt sich um einen OAuth-Ablauf. Die Bibliothek übernimmt dies. 5 Punkte.“

Sicherheit: „Welcher Identitätsanbieter (IdP)? Okta? Azure AD? Benutzerdefiniertes SAML?“

Backend: „…spielt das eine Rolle?“

Sicherheit: „Ja. Ihre Angaben entsprechen nicht den Angaben in der Spezifikation.“

Leitfrage: „Hat bereits jemand in diesem Team eine Anbindung an seinen IdP vorgenommen?“

SRE: „Wie sieht der Rollback aus, wenn es bei der Hälfte unserer Nutzer zu Ausfällen kommt?“

Die Frage des Projektleiters ist entscheidend für die Schätzung. Wenn bereits jemand mit diesem Anbieter zusammengearbeitet hat, ist das Feature klein und klar abgegrenzt. Ist dies nicht der Fall, besteht das Feature aus zwei Arbeitsteilen mit unbekanntem Umfang. Der richtige Schritt besteht nicht darin, eine genauere Schätzung vorzunehmen, sondern einen Spike unter Berücksichtigung des tatsächlichen Verhaltens des Anbieters zeitlich zu begrenzen und den Umfang der Implementierung erst danach festzulegen.

Fragen, die man sich vor der Stimmabgabe stellen sollte

• Um welchen Identitätsanbieter handelt es sich konkret? Okta, Azure AD, Google Workspace, Auth0 oder eine eigene Lösung?
• Hat jemand aus dem Team bereits eine Integration mit diesem Anbieter durchgeführt?
• OAuth, SAML oder OIDC? Und welche Version jeweils?
• Wie lautet das Modell zur Benutzerverwaltung: JIT, SCIM oder manuell?
• Zuordnung von Gruppen zu Rollen: Brauchen wir sie? Wo wird diese Zuordnung gespeichert?
• Was geschieht mit den bestehenden lokalen Konten während der Umstellung?
• Sitzungszeitlimit, Inaktivitätszeitlimit, MFA-Durchsetzung: Welche Richtlinie hat Vorrang?
• Können wir Tests mit dem tatsächlichen Provider des Kunden durchführen oder nur in einer Sandbox?

Sollten zwei oder mehr dieser Punkte als „das ist ein eigenständiges Ticket“ zurückgemeldet werden die Aufgabe ist zu umfangreich: Teilen Sie die Bereiche Bereitstellung, Rollenzuordnung und Migration in eigene Aufgaben auf und legen Sie den Umfang des Authentifizierungsablaufs separat fest.

Geben Sie keine Nummer ab, bevor Sie nicht wissen, mit welchem Identitätsanbieter Sie eine Integration vornehmen. Der Anbieter ist entscheidend.

Weitere Informationen zum entsprechenden Muster „Eigenheiten eines Drittanbieters“ finden Sie unter Schätzung eines API-Wechsels bei einem Drittanbieter, weitere Beispiele für gelungene Schätzungen finden Sie hier. Starten Sie eine kostenlose Planning-Poker-Sitzung, sobald der Spike geklärt hat, um welchen Anbieter es sich handelt und welche Eigenheiten zu beachten sind.