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

So schätzen Sie den Aufwand für eine SSO-Integration ein: Der Aufwand liegt nicht in Ihrem Code, sondern in den Besonderheiten des Identitätsanbieters. Die Fragen, die Sie klären sollten, bevor Sie eine Zahl festlegen.

Bei SSO geht es meist um die Eigenheiten anderer – richten Sie zunächst den Identitätsanbieter ein; 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-Bezeichnungen, 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 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? 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: „Was ist die Ausweichlösung, falls es bei der Hälfte unserer Nutzer zu Ausfällen kommt?“

Die Frage des Projektleiters ist ausschlaggebend für die Schätzung. Hat bereits jemand mit diesem Anbieter gearbeitet, ist die Aufgabe überschaubar und klar abgegrenzt. Hat dies noch niemand getan, besteht die Aufgabe aus zwei Arbeitspaketen mit unbekanntem Umfang – und der richtige Ansatz besteht nicht darin, die Schätzung noch genauer vorzunehmen, sondern einen Spike-Test 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 sieht das Modell zur Benutzerverwaltung aus – JIT, SCIM oder manuell?
  • Zuordnung von Gruppen zu Rollen: Brauchen wir sie? Wo wird diese Zuordnung gespeichert?
  • Was geschieht mit 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 finden Sie unter Schätzung eines API-Wechsels zu einem Drittanbieter zum entsprechenden Muster „Eigenheiten eines anderen Anbieters“ sowie in den anderen Beispielen für gelungene Schätzungen. 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.