Een schatting maken van een SSO-integratie

Bij SSO gaat het vooral om de eigenaardigheden van anderen — zorg eerst dat de identiteitsprovider goed werkt; de rest is slechts techniek.

“SSO toevoegen” klinkt als één functie. Het zijn er echter twee. De eerste is een klein onderdeel van de OAuth-, SAML- of OIDC-infrastructuur — goed gedocumenteerd, er zijn bibliotheken voor beschikbaar en elke moderne authenticatiebibliotheek heeft een handleiding. De tweede is alles wat de identiteitsprovider doet en wat niet in de handleiding staat: de claimnamen die niet overeenkomen met de specificatie, de regels voor de omleidings-URI die strenger zijn dan in de specificatie, de time-out van de sessie die niet overeenkomt met die van u, de afwijking van één bij het serialiseren van groepen, het metadata-eindpunt dat op dinsdagen ongeldige XML retourneert. Het eerste deel is het verhaal waar iedereen op kan stemmen. Het tweede deel zijn de punten.

Dat betekent dat de schatting niet echt betrekking heeft op SSO. Het gaat om deze identiteitsprovider, en of iemand in het team hier al eerder een integratie mee heeft uitgevoerd. Okta met een standaard SAML-configuratie is iets heel anders dan Azure AD met een aangepaste claimregel die niemand aan beide kanten volledig begrijpt. Een team dat een Okta-integratie binnen één sprint oplevert, zal drie sprints nodig hebben voor een federatieve AD FS-implementatie met een aangepaste proxy ervoor — en de code die zij uiteindelijk schrijven, ziet er vrijwel identiek uit.

Wat er in de kamer wordt gezegd

Backend: “Het is een OAuth-stroom. De bibliotheek regelt het. 5 punten.”

Beveiliging: “Welke IdP? Okta? Azure AD? Aangepaste SAML?”

Backend: “…maakt dat iets uit?”

Beveiliging: „Ja. Hun beweringen komen niet overeen met die in de specificaties.”

Inleiding: “Heeft iemand in dit team al eens een integratie met zijn of haar IdP uitgevoerd?”

SRE: „Wat is de terugdraaiingsprocedure als het bij de helft van onze gebruikers niet meer werkt?”

De vraag van de projectleider is bepalend voor de schatting. Als iemand al eens met deze provider heeft gewerkt, is het verhaal klein en goed afgebakend. Als niemand dat heeft gedaan, bestaat het verhaal uit twee stukken werk waarvan de omvang onbekend is — en de juiste aanpak is niet om een nauwkeurigere schatting te maken, maar om een spike uit te voeren binnen een tijdslimiet, waarbij het daadwerkelijke gedrag van de provider wordt onderzocht, en de implementatie daarna op maat te maken.

Vragen die u zich het beste kunt stellen voordat u gaat stemmen

• Welke identiteitsprovider precies? Okta, Azure AD, Google Workspace, Auth0 of een eigen oplossing?
• Heeft iemand binnen het team al eens een integratie met deze aanbieder uitgevoerd?
• OAuth, SAML of OIDC — en welke versie van elk?
• Wat is het model voor het aanmaken van gebruikersaccounts — JIT, SCIM of handmatig?
• Koppeling tussen groepen en rollen: is dit nodig? Waar wordt deze koppeling opgeslagen?
• Wat gebeurt er met bestaande lokale accounts tijdens de overgang?
• Time-out van de sessie, time-out bij inactiviteit, afdwinging van MFA — welk beleid prevaleert?
• Kunnen wij testen met de daadwerkelijke provider van de klant, of alleen in een sandbox?

Indien twee of meer van deze punten worden aangemerkt als „dat is een apart project“ het verhaal is te omvangrijk: splits dan de provisioning, de roltoewijzing en de migratie op in afzonderlijke verhalen en bepaal de omvang van de authenticatiestroom op zichzelf.

Stem pas op een nummer als u weet met welke identiteitsprovider u gaat integreren. De provider is waar het om draait.

Zie het inschatten van een overstap naar een API van een derde partij voor het gerelateerde patroon „de eigenaardigheden van een ander”, en de andere praktijkvoorbeelden van schattingen voor meer informatie. Start een gratis planning poker-sessie zodra uit de spike is gebleken welke aanbieder en welke eigenaardigheden er in het spel zijn.