VPN-side til ændring af adgangskode: matchet med identitetslageret

Åbn siden til ændring af adgangskode, og læs den, som en bruger ville, og spørg derefter, hvilken tjeneste der reelt ejer legitimationsoplysningerne. Siden er en formular; identitetslageret er autoriteten. Hvis de to er uenige, møder brugeren en afvist adgangskode, en nulstilling der ikke nulstiller noget, eller en succesmeddelelse der ikke ændrer noget. At følge flowet fra skærmen til backenden er den eneste måde at fange det.

Begynd med at klassificere handlingen: en normal ændring, et flow for udløbet adgangskode eller gendannelse efter en glemt adgangskode.

Tre handlinger, tre arbejdsgange

En normal ændring forudsætter, at brugeren kender den nuværende adgangskode og kan bevise det. Et flow for udløbet adgangskode kan tillade en begrænset session, hvor kun ændringen er tilladt. Gendannelse efter en glemt adgangskode kræver et helt andet identitetsbevis og kan delegeres til en identitetsudbyder i stedet for at blive håndteret ved VPN-gatewayen. Hver har sit eget endepunkt, backend-understøttelse og sessionsregler, og én formular kan ikke betjene alle tre korrekt.

I en fødereret udrulning indsamler gatewayen muligvis slet ikke en ny adgangskode. Kontroller, om flowet omdirigerer til identitetsudbyderen, og om sidens tekst stadig beskriver en lokal formular.

Hvor politikken egentlig kommer fra

Spørg identitetsejeren om den tilladte længde, tegnsættet og eventuelle gældende begrænsninger, og skriv derefter instruktioner, der matcher. At opfinde sammensætningsregler i hjælpeteksten eller love en accept, som backenden afviser, giver begge supportbilletter. NISTs vejledning om digital identitet hælder mod klar vejledning og nyttig feedback frem for vilkårlige regler, mens organisationens reelle politik stadig gælder. En publikation er ikke bevis på, at en bestemt mappe allerede opfører sig sådan.

Hold fejlmeddelelser nyttige uden at lække hemmeligheder. En meddelelse, der gengiver en delvist indtastet adgangskode, eller et skærmbillede i en billet, der indeholder en, gør et supportartefakt til en afsløring af legitimationsoplysninger.

Formuleringer, der matcher backenden

Siden bør navngive arbejdsgangen i stedet for at beskrive politik abstrakt. Sig, hvor ændringen sker, hvilket bevis der kræves, og hvad der sker med andre sessioner. Hvis ændringen logger brugeren ud overalt, så sig det; hvis den lader andre enheder være aktive, så sig det også. En forvirret bruger, der gentager en vellykket ændring, er en supportomkostning, som bedre formulering forhindrer.

Lokalisering kan ændre tonen i instruktionerne; den kan ikke ændre, hvad backenden accepterer.

Test flowet, ikke siden

Brug en tilladt testkonto, og gennemgå den dokumenterede ændring, et afvisningstilfælde, tilfældet med udløbet adgangskode og det efterfølgende login. Hvor MFA eller en fødereret omdirigering er en del af det godkendte flow, så gennemgå det også. En side, der vises korrekt, har verificeret præsentationen og intet andet, fordi identitetstjenesten afgør, om legitimationshandlingen blev fuldført.

Registrer resultatet af hvert tilfælde med den anvendte konto og tidspunktet. Et flow, der virker én gang for en administrator og fejler for en normal bruger, er et almindeligt udfald, og registreringen er det, der gør det synligt.

Opdater derefter siden, så den beskriver, hvad der faktisk skete. Det er hele opgaven.