Groen eenheidstoetse beteken nie jy kan regstreeks gaan nie
Ons verkoop verifikasie, wat ons skrikwekkendste vraag 'n eenvoudige een maak: wanneer 'n klant hulle toepassing aan ons koppel en alles aanskakel, werk dit werklik, end tot end, op die regte ding? Nie "slaag die eenheidstoetse," nie, maar registreer 'n splinternuwe huurder, konfigureer SSO en SCIM en MFA en pasgemaakte aansprake en handelsmerk, rig 'n werklike toepassing daarop, en meld 'n werklike gebruiker met die regte aansprake in die token aan, deur 'n werklike webblaaier. Ons beantwoord dit op die enigste manier wat ons vertrou: met een end-tot-end-toets wat 'n klant word.
Dit is 'n enkele Playwright-lopie, doelbewus serieel en toestandvol, en dit loop deur die hele lewe van 'n huurder, van geboorte tot verwydering. Een huurder registreer, word tot in die fynste besonderhede gekonfigureer, bedien 'n werklike aanmelding aan 'n werklike verbruikerstoepassing, word gerugsteun en herstel, en vee dan homself uit. As enige skakel in daardie ketting breek, word die lopie rooi, en ons stuur dit nie uit nie.
Dit konfigureer alles, nie net 'n stukkie van die gelukkige pad nie
Die middel van die toets is doelbewus deeglik. Dit meld nie net aan en noem dit klaar nie; dit loop deur elke skerm wat 'n werklike implementeerder aanraak en oefen dit eg uit: 'n pasgemaakte OIDC-kliënt met sy herleidings-URI's en token-instellings, 'n pasgemaakte omvang wat gebruikersaansprake uitstuur, rolle en 'n roltoewysing, 'n eindgebruiker met 'n pasgemaakte attribuut, 'n groep met werklike lidmaatskap en 'n groep-tot-rol-kartering, SAML- en OIDC-ondernemingverbindings, 'n SCIM-voorsieningstoken, 'n pasgemaakte domein, 'n uitgaande voorsieningstoepassing, 'n spanmaat wat genooi en herrol word, fakturering deur 'n werklike betaalafhandeling, die ouditlogboek met filters en 'n CSV-uitvoer, 'n sandbox-omgewing, en die sekuriteit-, webhook- en e-pos-instellings (elkeen omgeskakel, dan teruggestel na 'n veilige toestand). Elkeen daarvan word geskep, geverifieer, en waar dit sin maak uitgevee, in dieselfde lopie.
Die doel is nie om blokkies af te merk nie. 'n Klant gebruik nooit een kenmerk in isolasie nie; hulle gebruik 'n kombinasie, en kombinasies is waar dinge stilweg breek. 'n Pasgemaakte aanspraak maak net saak as dit in die uitgereikte token verskyn. 'n Groep-tot-rol-kartering maak net saak as die rol op presies die oomblik land wanneer die token geskep word. Die enigste manier om te weet is om die hele ding te bou en dit dan te gaan gebruik.
Die geloofsbriewe-dans
Hier is die deel wat 'n end-tot-end-toets van 'n verifikasieproduk werklik ongemaklik maak: die geloofsbriewe bestaan nie wanneer die toets begin nie. Jy kan nie 'n kliëntgeheim of 'n SCIM-token hardkodeer nie, want die hele punt is dat die huurder hulle vars skep gedurende die lopie.
So die toets doen presies wat 'n werklike implementeerder doen, net vinniger. Dit skep die OIDC-kliënt in die portaal en lees die kliënt-ID en -geheim terug. Dit skep 'n Portal API-geloofsbrief met een klik en vang dit op. Dit genereer 'n SCIM-token. Dan voer dit elkeen van daardie vars geskepte geheime in die voorbeeld-verbruikerstoepassing wat gereed staan, herskryf daardie toepassing se konfigurasie met die nuwe waardes, ontplooi dit, en dryf eers daarna die werklike aanmelding. Geloofsbriewe wat in een stap gebore word, word in die volgende in die toepassing onder toets ingespuit, en die webblaaier voltooi 'n werklike OIDC-herleiding daarteen. Die integrasie is 'n bewegende teiken wat die toets aanhou herrig op homself soos dit vorm aanneem.
Daardie verbruiker is 'n werklike ontplooiing, nie 'n namaaksel nie. Wanneer die toets 'n aanmelding verifieer, het 'n werklike toepassing werklik na die huurder se uitreiker herlei, werklik 'n kode teruggekry, dit werklik omgeruil, en die toets dekodeer die gevolglike token om te bevestig dat die pasgemaakte aanspraak en die gekarteerde rol werklik daarin is. Dan dryf dit die moeiliker rande: 'n pasgemaakte handelsmerk-aanmeldbladsy agter sy aktiveringshek, en 'n afgedwonge webhook wat 'n aanmelding moet blokkeer wat die beleid weier. 'n Groen toets op daardie laaste een beteken die weierpad werk, wat die resultaat is waarvan jy die seerste seker wil wees.
Multifaktor, regtig
'n Wagwoordaanmelding bewys op sy eie min. Die lopie registreer en gebruik dan 'n TOTP-verifikator en 'n WebAuthn-geloofsbrief deur 'n virtuele verifikator, sodat die tweede faktor uitgeoefen word soos dié van 'n werklike gebruiker, nie met 'n stub vervang nie.
Die helfte wat almal oorslaan: om dit terug te kry
Die meeste end-tot-end-toetse stop by "dit werk." Ons s'n gaan voort tot in die dele waaraan jy net om 2vm dink. Dit neem 'n rugsteun, vee die huurder se data onder homself uit, herstel vanaf daardie rugsteun, en verifieer dat die konfigurasie en gebruikers ongeskonde teruggekom het. Dan voer dit 'n skoon selfdiens-verwydering van die hele huurder uit. 'n Lopie laat niks agter nie, wat ook is hoe ons weet dat ontvoorsiening werklik ontvoorsien.
Hoekom dit die toets is wat ons vertrou
'n Muur van groen eenheidstoetse sê vir jou jou funksies is korrek. Hierdie sê vir jou 'n klant kan instap, die integrasie bou wat hulle werklik wil hê, met die sekuriteitskenmerke wat hulle werklik nodig het, en dat ons hulle data kan verloor en dit kan teruggee. Dit is die verskil tussen "die kode is korrek" en "ons kan regstreeks gaan."
Elke kenmerk wat hierdie lopie uitoefen (SSO en SAML, SCIM, MFA, pasgemaakte aansprake en omvange, handelsmerk, afgedwonge webhooks, oudituitvoer) is in die produk by elke vlak, nie agter 'n ondernemingsopverkoop versper nie. Sien wat ingesluit is.