Implementering af en single sign-on-løsning kan være kompliceret, især hvis du har apps, der ikke findes i SSO-leverandørkataloget.
Hvordan ved man, at det indkøbte SSO-produkt fungerer korrekt? Et simpelt spørgsmål, der måske er knap så simpelt at besvare. Konfiguration af de automatiske login kræver en forståelse af de godkendelsesprotokoller, som de bruger. Desuden kræver det viden om hvordan de forskellige programmer bruger godkendelsesprotokoller, både lokalt og SaaS, til at kode dem korrekt på SSO-portalen.
Mens de store SSO-leverandører understøtter hundredvis af apps, er nogle af dem, især dine egne ”hjemmelavede” apps, muligvis ikke allerede i leverandørens kataloger. Nogle SSO-leverandører har værktøjer eller konsulenter (tilgængelige enten som en del af det oprindelige køb eller mod et ekstra gebyr) til at hjælpe med dette.
Ville det ikke være rart, hvis du kunne køre et automatiseret testværktøj for at finde ud af, hvor din SSO-software svigter?
Tre scenarier, hvor det er nyttigt
- Når dine app-leverandører foretager små ændringer af deres loginskærme og disse ændringer kan rejse dine automatiseringsrutiner, der får dit SSO-login til at mislykkes. De store SSO-leverandører hævder, at de har måder at holde styr på dette, men hvis de ikke gør det, vil dine brugere normalt fortælle dig det, før du kan finde ud af problemet.
- Når du udruller en ny app, enten en offentlig SaaS-app eller noget, du har udviklet internt og vil sikre dig, at din SSO-forbindelse fungerer korrekt.
- Når en ondsindet aktør udnytter deres vej ind i din virksomhed.
For at dække alle scenarier har du 2 grundlæggende valg
Det første valg er at bruge de testværktøjer, der er angivet af din SSO-leverandør. Problemet er, at det ikke altid er let at finde disse værktøjer. Mange leverandører behandler værktøjerne som mere et sideudviklingsprojekt, snarere end noget de tilbyder med deres almindelige produktlinjer.
Det andet valg er at overveje et tredjepartstestværktøj. En voksende samling af værktøjer kan hjælpe dig med at finde ud af, om du har konfigureret de mange variabler, kryptografiske kendetegn og politikker korrekt.
En mulighed er at anvende et CLOUD ACCESS-sikkerhedsmæglerværktøj (CASB). Disse gør andre ting ved siden af automatisere login til dine SaaS-apps, såsom at tilføje et andet sikkerhedslag.
Testværktøjer fra større SSO-leverandører
Første gang du afprøver din SSO-implementering, har du typisk en lille testgruppe af brugere for at sikre, at den fungerer efter hensigten til et udsnit af dine apps. Nogle SSO-leverandører kan oprette et testmiljø for at finde ud af fejlene, f.eks. klargøring og uddeling af brugere, og identifikation af ukendte apps, der kræver yderligere opmærksomhed.
Her er det, hvor tingene bliver interessante. Hvis dette er din første eksponering for SAML-protokollerne (Security Assertion Markup Language), OpenID Connect og OAuth-protokoller (Open Authorization), skal du have hjælp til, hvordan SSO-leverandøren implementerer dem. Alle leverandører har rigelig (og næsten ulæselig) dokumentation. Det er her testværktøjerne kan være nyttige, fordi de ikke kræver, at du studerer protokolsyntaksen, men tilbyder en mere menneskevenlig grænseflade.
To SSO-leverandører har oplysninger om SSO-test, der er gode startsteder, især hvis du ikke kender forskellen mellem en SAML-tjenesteudbyder og identitetsudbyder. Du behøver ikke at være kunde for at bruge de fleste af disse værktøjer.
NetIQ’s (rebranded af Microfocus som CyberRes) serie af offentlige SAML biblioteker omfatter en bredere samling af programmeringssprog.
OneLogins serie af SAML-testværktøjer er tilgængelige på forskellige sprog (PHP, Python, Ruby, Java og .NET). Et dejligt plus er, at de alle er tilgængelige på GitHub. For nylig udgav de nye workflow automation-produkter, der skulle gøre det lettere at understøtte generelle klargøringsopgaver.
Du bør sandsynligvis have en separat testforekomst for hele dit webappmiljø, så du kan eksperimentere med SSO uden at skade dine produktionssystemer. Fire leverandører har sammensat disse:
NetIQ (ud over værktøjerne ovenfor) har sin Access Manger OAuth Playground, hvor du kan prøve tingene, hvis du bruger deres eget identitetsstyringsprodukt.
CyberArk har forskellige SAML-forhåndsvisningsværktøjer til at validere den kode, der genereres til sine apps.
Ping Identity har sin OAuth Playground, også til dette formål. Du kan eksperimentere med OAuth- og OpenID Connect-scripts uden at skade dine produktionssystemer.
Okta har noget lignende med sit integrationsnetværk. Det har indbyggede stik til tusindvis af apps og meget mere, herunder værktøjer til yderligere sikkerhed, analyse og run-of-the-mill SaaS-apps. Der er også rigelig dokumentation om, hvordan du opretter dine egne integrationer, sammen med guider til oprettelse af SAML- og OpenID Connect-integrationer. Selvom det er meget at gennemgå, er chancerne i det mindste store for, at de er stødt på de fleste af de apps, som dine brugere kører.
Hvis du bruger andre SSO-produkter, skal du ty til et kludetæppe af værktøjer
Auth0 (som er fusioneret med Okta) tilbyder hjælp til fejlfinding af SAML-implementeringer, men de manuelle trin til løsning af forskellige fejlmeddelelser kan være kedelige. Du kan vælge en speciel fejlfindingstilstand for at få en mere detaljeret række fejlmeddelelser. De har også opbygget en tjeneste, der opretholder ændringer i tjenesterne, når de er oprettet. Selvom du ikke bruger Auth0, er dette en nyttig klar reference, hvis du vil vide mere om fejlfinding af SAML.
Tredjeparts SSO-testværktøjer
Problemet med SSO-leverandørværktøjssættet er, at du ikke har nogen måde at automatisere test på tværs af hele din applikationsinfrastruktur.
Mange testværktøjer kommer fra det generelle testautomatiseringsrum, hvilket betyder, at disse leverandører kan teste meget mere end dine SSO-applikationer. Det er både gode og dårlige nyheder. Godt, fordi det viser, at automatiseringsleverandørerne endelig er opmærksomme på at løse SSO-problemer. Dårligt, fordi antallet af SSO-kunder stadig er en lille delmængde af hver leverandørs brugerbase, hvilket betyder, at det kan være en udfordring at finde en kyndig supportperson.
Værktøjerne tilbyder fælles funktioner
Automatisk registrering af fejl. Hvis et loginscript mislykkes, kan du identificere det, før dine brugere ringer for at klage.
Hurtig oprettelse af nye testscripts. Når du mestrer værktøjets ins og outs, kan du generere nye scripts inden for få minutter. Det bør også være nemmere at skrive scripts end at fejl i SAML- eller JSON-kode.
Test af softwaresårbarhed
Hvis du bruger Okta’s SSO-modul, kan du prøve de fleste af disse automatiseringsværktøjer og se, hvilken du bedst kan lide. Hvis du bruger Auth0, Ping eller noget andet, så har du mere begrænsede muligheder.
Test af sikkerhedssvaghed
Hvis du sammensætter en SSO-implementering, vil du sandsynligvis have et par problemer for at sikre, at en hacker ikke smutter gennem din infrastruktur. I et ekstremt eksempel var en hacker i stand til at forgifte kryptografiske kendetegn for eskalerede rettigheder for Active Directory.
Andre omstændigheder er mere almindelige, f.eks:
- Kan du nemt finde ud af, om brugere, der ikke længere er ansat, er blevet fjernet fra dine logins?
- Kan du søge efter unødvendige administratorbrugere eller simple adgangskoder eller forkert konfigurerede netværkszoner?
- Kan du analysere en leverandørs SSO-log og i bekræftende fald, hvordan gøres dette?
Generelle sårbarhedsscannere kan ikke udføre nogle af disse opgaver, fordi de ikke nødvendigvis fokusere på helligheden i dit SSO-system.
Nogle nye tredjepartsværktøjer kan hjælpe, især hvis du kører Oktas SSO-miljø. Andre SSO-leverandører har været langsomme til at udvikle bedre automatiserede metoder. Hvis du bruger Okta, Ping, CyberArk eller Auth0 SSO, skal du starte med deres værktøjer. Hvis du har noget andet, skal du starte med enten OneLogin eller NetIQ’s kodebiblioteker. Tilføj derefter dit automatiseringslag med det værktøj, du kender bedst.
Kilde: CSO