Sådan vælger du den bedste godkendelse som tjenesteudbyder til din virksomhed

Har du nogensinde spekuleret på, hvordan du vælger en udbyder af godkendelsestjenester?

Vi er midt i en voksende tendens til at bruge fødererede identifikatorer til at give godkendelse til de websteder, vi bruger hver dag.

Vi kan logge ind på utallige applikationer ved hjælp af vores sociale mediekonti, vores arbejdskonti har alle SSO-funktioner, og vi kan endda logge ind på offentlige websteder ved hjælp af vores online-bankoplysninger.

Konceptuelt er godkendelse (og SSO) enkel, men det er svært og dyrt at implementere korrekt. Selvom virksomheder traditionelt har fokuseret på at opbygge funktioner, skal de nu i virkeligheden også fokusere på at sænke brugerregistreringskonflikt uden at udsætte applikationen for sårbarheder. Ligesom hvordan cloudinfrastrukturplatforme (som AWS) nu giver virksomheder mulighed for at fokusere på at bygge apps, ser vi det samme lykkeligt med godkendelse.

Godkendelse som en tjeneste (eller godkendelsestjenesteudbydere) leverer godkendelses- og brugeradministrationstjenester til applikationer.

De er ikke kun en identitetsudbyder, men giver konfigurerbare brugerloginsider (eller widgets), logoutfunktionalitet, forenede identiteter med sociale mediekonti, brugerdatabaser og en vis grad af brugeradministration. De har out of the box-funktioner til at understøtte almindelige godkendelsesprotokoller som SAML og OpenID Connect.

Virksomhedskunder, der ønsker SSO, kan ofte drage fordel af nemme opsætninger med et enkelt klik med tredjepartsapplikationer som JIRA, Office 365 og Salesforce gennem brug af SAML2.

Hvad er dine mål?

Til tider kan implementering af godkendelsessystemer til en applikation føles som at genopfinde hjulet. Begrebet godkendelse som en tjeneste (AaaS) forsøger at løse dette problem, men der er ting, man skal overveje, før man vælger en udbyder (eller beslutter at udrulle en brugerdefineret løsning).

Kriterier

Når du først er kommet med en liste over vigtige overvejelser for din organisation, er det tid til at begynde at evaluere godkendelsen som tjenesteudbydere (AaaSp) på markedet. I de sidste par år har vi set et antal AssSp komme ind og forsvinde. Dette gør valg af den rigtige AaaSp så meget mere kritisk. De kommer i alle former og størrelser - fra små firmaer med små kunder til store etablerede virksomhedsudbydere.

Tillid og omdømme

At betro noget så vigtigt som godkendelse kræver en betydelig tillid, så det er vigtigt, at den valgte sælger skal være velrenommeret og en betroet autoritet inden for godkendelse. Overvej om deres arkitektur er blevet gennemgået af andre sikkerhedseksperter, og gennemgå enhver online kommentar om udbyderen.

Som vi har set med Stormpath (købt af Okta i 2017 og derefter droppet Stormpath API), åbner risikoen for tilbagelevering af vender ved at videresende til en tredjepartsleverandør . I værste fald, som det var med den ovennævnte erhvervelse, var mange tilbage uden migrationssti fra Strompath til Okta og var forpligtet til at udrulle deres egne autentificeringssystemer.

Venderstørrelse, kundeliste og virksomhedsprofil er generelle retningslinjer, der kan tages i betragtning, men du tager stadig en risiko. Mindre startudbydere kan tilbyde betydelige incitamenter, men deres evne til at forsvinde hurtigt uden ordentlig varsel kan gøre dem til et risikabelt valg. Alternativt kan større udbydere stadig lukker deres tjenester, hvis denne branche ikke længere bliver rentabel.

Tilsigtede brugere

Nogle AaaS-udbydere, såsom One Login, fokuserer udelukkende på B2E - der giver en virksomheds interne medarbejdere en SSO-oplevelse med deres webbaserede tjenester. Tænk på firmaportalsider med links til HR-ressourcer, firmaet Wiki, Sharepoint og Salesforce. Auth0 og AWS Cognito er udbydere, der betjener både B2E og B2C og understøtter eksplicit klienter, der har hundreder af tusinder af kunder.

Vender-lås

Integration med en AaaSp introducerer en mere betydelig indbyrdes afhængighed, så integrering af en applikationsstak i en skybaseret løsning, fordi leverandørspecifik kode skal skrives for at afslutte integrationen.

Dette skal ikke kun fortrydes, men der skal skrives mere integrationskode til den nye udbyder. At flytte fra en AaaS til at udrulle en brugerdefineret løsning er endnu dyrere, da alt skal skrives fra bunden.

I modsætning til ændringer i infrastruktur, hvor der findes afbødningsstjerner for at reducere brugerafbrydelse, vil bytte af AaaS-udbydere næsten altid påvirke brugerne. Husk, vi ændrer komponenter, der direkte interagerer med slutbrugere.

Import af data

De fleste AaaS-udbydere definerer en mekanisme til import af brugere til deres system ved bulkimport (hvor brugere skal gennemgå en nulstillingsstrøm for adgangskode) eller gradvis migrationsproces. Med den gradvise migrering valideres brugerlegitimationsoplysninger først mod den gamle database og krypteres derefter og lagres i den nye database. I dette brugssag er brugerne ikke påvirket af migrationen.

Dataeksport

Denne funktion er især vigtig i det tilfælde, hvor applikationer bruger AaaS's datalager. Af sikkerhedsmæssige årsager offentliggør AaaS-udbydere ikke deres algoritme til hash-adgangskode. Derfor, når en eksport er påkrævet, skal alle brugere starte et flow til nulstilling af adgangskode.

Hvis det ikke lyder dårligt nok, leverer mange AaaS-udbydere IKKE en bulkdataeksportfunktion, hvilket tilføjer ekstra kompleksitet og manuelle trin til at migrere brugerdata ud af en AaaS.

Underleverandører

Nogle tjenester, der tilbydes af AaaS-udbydere, opfyldes af endnu en tredjepartstjeneste. 2fa / mfa og e-mail er undertiden funktioner, der kræver separate registreringer (og yderligere betaling) hos tredjepart.

Hvis vi tager 2FA som et eksempel, tillader nogle AaaS-tjenester dig ikke at vælge den underliggende 2FA-udbyder og tvinge dig til at bruge deres foretrukne vender. Ikke kun bliver du tvunget til at gå i partnerskab med denne vender, men du er også tvunget til at betale deres satser (hvor der undertiden er billigere alternativer).

Teknologisk support

Protokoller

De fleste AaaS-udbydere understøtter de største federerede protokoller (OpenID Connect og SAML). Andre har yderligere stik, der muliggør tilpassede datakilder (Microsoft AD eller LDAP) og nemme opsætninger til tredjepartsapplikationer som JIRA, Office 365 og Salesforce gennem brug af SMAL.

Integration

Integration af AaaS-tjenesten i din applikation kan stadig være en vigtig opgave (især hvis du kører en ældre applikation). Derfor er en overvejelse at se, om AaaS tilbyder biblioteker til din teknologiestak.

For eksempel: De fleste større AaaS-udbydere sammen med sociale mediewebsteder giver klientbiblioteker til at anmode om, forbruge og validere forskellige godkendelsestokens og dokumenter. Hvis du kører en Java-stak, tilbyder mange tjenester Java-biblioteker, der skal inkluderes i dit projekt til enhver backend-behandling. Hvis din stak understøttes, kan integrationsprocessen være så enkel som at droppe en JS-fil, inklusive en JAR, og udfylde nogle værdier i en egenskabsværdi.

Dokumentation

Rigelig, velskrevet dokumentation og samfundsstøtte vil gøre en lang vej for at gøre integrationen lettere. Nogle udbydere tilbyder så- og prøveprojekter for at komme i gang.

Andre funktioner

Mange tjenester tilbyder tilføjelsesfunktioner såsom brugerprofilering, e-mail og 2fa / mfa.

Brugergrænseflader og -flow, der kan tilpasses

AaaS-udbydere tillader forskellige niveauer af tilpasning til UI-sider, widgets og brugerattributter. Derudover har nogle systemer “kroge”, hvor tilpasning af strømme kan finde sted (check out Auth0 og AWS Cognito for flere detaljer).

Afhængigt af din specifikke organisation kan det være svært at finde balancen mellem at møde UX-ønsker og hvad der kan tilpasses (inden for grund) af udbyderen. I nogle tilfælde understøttes forretningsstrømme muligvis ikke af dit valgte AaaS.

En note om tilpasning:

Klar out-of-the-box-godkendelsesfunktioner er en af ​​de store fordele ved at bruge en AaaSp. Når de forudbyggede komponenter bruges, er integrationen utrolig enkel.

På den anden side øger kraftig tilpasning af brugergrænsefladen og strømme tid og kompleksitet. Du kan finde dig selv så tungt og omfattende at tilpasse brugergrænsefladen og godkendelsesstrømme, at du skal stille spørgsmålstegn ved, om det vil være billigere at udrulle en brugerdefineret intern løsning (også i betragtning af de årlige omkostninger). Svaret kan være JA .

Min anbefaling er at tilbageholde så meget tilpasning som muligt inden for AaaS-rammen. Dette er især tilfældet, når det kommer til godkendelse og nulstilling af adgangskode, da tilføjelse af tilpasning til disse komponenter har en tendens til at øge kompleksiteten af ​​integration og skabe leverandørlås.

Support til udvikling og test

Udviklings-, kvalitets- og produktionsmiljøer

Nogle virksomheder har isolerede udviklings- og kvalitetsmiljøer. For at understøtte disse krav tillader nogle AaaS-udbydere, at en enkelt konto har flere identitetsdatabaser. Dette er desværre ikke en universel funktion, og flere konti med AaaS kan være nødvendige for at understøtte hvert testmiljø.

Load Testing

Alle AaaS-systemer forbyder uautoriseret belastningstest. Dette kan være et problem, hvis din applikation kræver en end-to-end belastningstest for at blive godkendt til produktion. I dette tilfælde tillader nogle AaaS-udbydere belastningstest, hvis det er forhåndsgodkendt inden testen finder sted. Der er ofte strenge begrænsninger og tidsrammer, som testen skal køres under.

Mere realistisk er du sandsynligvis nødt til at implementere en login-bypass-mekanisme for applikationen til at understøtte belastningstest.

Priser

Prissætningsmodeller varierer betydeligt mellem AaaS-udbydere. Nogle udbydere har incitamenter til små opstartsorganisationer og har et gratis eller meget overkommeligt laveste niveau. Generelt forvent at se en pris / brugergraf som følgende:

Pris pr. Bruger er oprindeligt meget lav (eller $ 0), hvilket er fantastisk til små organisationer eller nystartede virksomheder med lave volumener. Når din brugerbase vokser, forbliver prisen / brugeren dog ens. Til sidst begynder det at falde efter et bestemt tidspunkt, fordi du enten har nået det højeste forbrugsniveau eller er i stand til at forhandle priser.

Omkostningerne kan synes rimelige, når du starter, men når du først er låst inde, kan en applikation med 100.000 aktive brugere om en måned se en årlig regning på 150.000 til 200.000!

Hvis din applikation allerede har en brugerbase på flere hundrede tusinde brugere, kan det være billigere at udrulle din egen løsning! Ud over gebyrer pr. Bruger er der ofte gebyrer for yderligere tjenester, du måtte pådrage (igen, 2fa og e-mail).

B2C

Forhandle pris, hvis din applikation har perioder med tung brug. Nogle tjenester har variabel pris pr. Møl baseret på antallet af faktiske aktive brugere, mens andre fastsætter prisen pr. Måned baseret på et skøn over den tungeste måned gennem året (uanset hvor mange brugere der faktisk bruger systemet). Forskellen mellem disse prisplaner kan være betydelig.

B2E

Priserne er altid sat til et beløb pr. Medarbejderkonto. Pas på minimumsgebyrer i det med småt!

Brugeradministration og Dashboard

De fleste AaaS har en eller anden form for grundlæggende brugeradministration indbygget i deres admin dashboards. I nogle tilfælde kan du oprette ikke-admin-konti til dine kundeservicemedarbejdere eller andre associerede for at foretage ændringer i brugeridentiteter.

At give fuldadministratorkonti til medarbejdere, så de kan få adgang til brugeradministrationsdashboardet, bør undgås . Administratorkontoen skal kun være i hænderne på de passende uddannede medarbejdere, ellers risikerer du, at nogen ved et uheld sletter hele din brugerdatabase eller afslører brugeridentiteter.

Uanset om det indbyggede AaaS-dashboard understøtter dine behov eller ej, er det specifikt for de daglige brugerattributændringer, som din organisation skal foretage. Sørg for, at AaaS leverer en passende sporings- / logspor i henhold til din organisations politikker.

SLA og kundeservice

En direkte kontakt med en kontoadministrator hos udbyderen tilbydes ikke på tværs af alle AaaS-udbydere. Gratis eller lavt anvendte niveauer får ofte kun adgang til fællesskabsfora. Nogle udbydere tilbyder betalt support, dedikerede servere, adgang til logfiler og HIPAA / PCI-overholdelse mod et ekstra gebyr.

De fleste AaaSp tilbyder standard 99,9% til 99,995% SLA oppetid, men dette giver stadig mulighed for nedetid i løbet af året. Dette kan være vigtigt, hvis din ansøgning skal være ope i kritiske perioder. Nogle AaaSp tilbyder virksomhedsløsninger (brugerdefinerede implementeringer) for at sikre en form for redundans i tilfælde af systemfejl.

Konklusion

For nystartede virksomheder tilbyder AaaSp en overkommelig løsning til godkendelse, så du kan fokusere på dit produkt. For større organisationer med ældre applikationer og en etableret brugerbase skal du tage en meget bredere liste over kriterier i betragtning for at sikre dig, at du vælger det AaaS, der passer til din migrations-, revision / logning- og budgetbehov.

Som opfølgning har jeg skrevet en introduktion til forenede identiteter og godkendelse.