Single sign‑on mod kundernes egne login: hvad skal testes?

Når en kunde kobler sit eget fælles login på jeres produkt, overlader kunden en del af adgangskontrollen til den kobling, og det er jer, der har bygget den. Svaret på, hvad testen skal dække, hviler på, at hver kunde har sin egen identitetsløsning, og at produktet skal holde dem adskilt: et login hos én kunde må aldrig give adgang hos en anden, og en bruger, kunden har fjernet, skal også være ude af produktet. Selve kundens identitetsløsning er kundens; koblingen i jeres produkt er jeres.

Det fælles login i en virksomheds egne systemer er beskrevet generelt for køberen på penetrationtest.dk. Her er situationen den omvendte: I er systemet, som mange forskellige kunders login skal kobles til.

Kundens login bliver en del af jeres produkt

Med single sign-on logger kundens medarbejdere ind med de samme oplysninger, som de bruger til alt andet i virksomheden. Kunden styrer adgangskoder, totrinsbekræftelse og fratrædelser ét sted. NCSC anbefaler i sine principper for cloudtjenester, at organisationer bruger single sign-on til at knytte brugernes identiteter til virksomhedens eget katalog, bl.a. fordi det gør det lettere at håndtere nye, flyttede og fratrådte medarbejdere.

For kunden er det en sikkerhedsforbedring. For jer betyder det, at produktet skal tage imod login fra mange forskellige identitetsløsninger og stole på hver af dem, men kun for den kunde, den hører til.

Hvorfor kunderne lægger vægt på det

Kunder, der kræver single sign-on, kan gøre det, fordi de vil have kontrollen samlet. Det giver nogle forventninger, som de regner med, at jeres produkt opfylder:

Kun deres login · at deres medarbejdere ikke kan omgå det fælles login med en lokal adgangskode, hvis de har valgt det fra.
Rettigheder fra kataloget · at grupper i deres katalog giver de rigtige roller i produktet.
Hurtig udelukkelse · at en medarbejder, der fjernes i kataloget, mister adgangen til produktet.
Ingen krydsning · at deres identitetsløsning ikke kan give adgang hos andre kunder, og omvendt.

Hver forventning er en grænse, testen kan afprøve.

Kravet kan komme sammen med et spørgsmål i kundens skema om, hvordan koblingen er sat op, og hvem hos kunden der kan ændre den. Hvis kunden selv kan sætte koblingen op i produktet, er den funktion også en del af det, testen skal se på, fordi den bestemmer, hvilken identitetsløsning produktet stoler på for netop den kunde.

Hvad testen afprøver

Testen ser på koblingen mellem kundernes identitetsløsninger og produktet:

Tilknytningen · er hver identitetsløsning bundet til netop én kunde, så et gyldigt login hos én kunde ikke giver adgang hos en anden? → Multi-tenant: test af adskillelsen mellem kunderne
Oversættelsen til roller · giver grupper og oplysninger fra kundens katalog de rigtige roller, og kan en bruger påvirke sin egen rolle? → Roller og rettigheder i produktet
Oprettelse ved første login · hvis produktet opretter brugere automatisk, sker det så kun hos den rigtige kunde og med den rigtige rolle?
Afslutningen · udløber sessionen, og forsvinder adgangen, når kunden fjerner brugeren?
Opsætningen · kan kun kundens administrator ændre koblingen, og kan den ændres til en anden kundes løsning?

Alt beskrives på begrebsniveau i omfanget. Den præcise fremgangsmåde er testerens.

Et fund i koblingen har en særlig karakter over for kunderne. Det rammer ikke kun den funktion, hvor fejlen sidder, men selve indgangen til produktet. Kunder, der har valgt single sign-on for at samle kontrollen, vil spørge, om nogen har kunnet komme ind uden om deres katalog. Vær klar til at svare ud fra jeres logs over login, og skelne mellem det, testen viste var muligt, og det, I kan se faktisk er sket.

Testerens identitetsløsninger

Testeren skal ikke bruge rigtige kunders identitetsløsninger. Til testen skal der i stedet være mindst to testlejere, som hver er koblet til en identitetsløsning, I eller testeren styrer. Kun på den måde kan testen afprøve, om et login fra den ene ender hos den anden. → Testlejere

Hvis produktet understøtter flere standarder eller flere kendte identitetsløsninger, så aftal, hvilke der er med. Kunderne bruger forskellige løsninger, og koblingen kan være bygget forskelligt for hver. Skriv i rapporten, hvilke der blev testet, så en kunde kan se, om deres egen type var med.

Login ved siden af det fælles login

I nogle produkter findes der stadig et lokalt login ved siden af single sign-on: til jeres support, til nødadgang, hvis kundens løsning er nede, eller til brugere, der blev oprettet, før kunden skiftede. Det er en anden dør ind, og den kan omgå alt det, kunden har sat op i sit eget katalog.

Testen skal derfor se på, om kunden faktisk kan slå det lokale login fra, og om det så også er slået fra i praksis. Nødadgangen er et legitimt behov, men den skal være synlig for kunden og styret. Jeres egne medarbejderes adgang er et emne for sig. → Supportadgang og administrationsmodul

Brugere, der forsvinder i kundens katalog

Kunden forventer, at en medarbejder, der stopper, mister adgangen til alt på én gang. Hvis produktet kun tjekker kundens katalog ved login, kan en åben session leve videre. Hvis produktet har nøgler eller tokens, som brugeren selv har oprettet, kan de også overleve.

Hvordan produktet håndterer det, er et designvalg, som I skal kunne forklare kunderne. Testen kan vise, om det virker, som I beskriver. Hvad kunden gør i sit eget katalog, er kundens ansvar. → Kundernes eget ansvar

Det skal I lade være med

Teste single sign-on med én testlejer · så kan grænsen mellem kundernes login ikke afprøves.
Bruge en rigtig kundes identitetsløsning i testen · brug testløsninger, I styrer.
Glemme det lokale login · det kan omgå kundens kontrol.
Antage, at fjernede brugere er ude · test, hvad der sker med åbne sessioner og nøgler.
Skrive single sign-on testet uden at angive hvilke løsninger · kunderne bruger forskellige.
Love kunderne, at deres eget katalog er sikkert · det er deres del.

Hvad kan og ikke kan konkluderes

En test af koblingen viser, om de testede identitetsløsninger blev holdt adskilt, gav de rigtige roller og lukkede adgangen som beskrevet i den testede version. Den siger intet om kundernes egne identitetsløsninger eller om typer af koblinger, der ikke var med.

Tjekliste til single sign-on i testen

☐ Har testeren mindst to testlejere med hver sin identitetsløsning?
☐ Er det aftalt, hvilke standarder og løsninger der testes?
☐ Er oversættelsen fra kundens grupper til roller med?
☐ Er det lokale login og nødadgangen med?
☐ Er det afprøvet, hvad der sker, når en bruger fjernes?
☐ Står de testede løsninger i rapporten?

Kilder

NCSC (UK): Principle 10, Identity and authentication: adgang til cloudtjenester for godkendte identiteter og anbefalingen om single sign-on mod organisationens eget katalog.

Senest gennemgået: oktober 2026.