VPN-side for passordbytte: samsvar med identitetslageret

Åpne siden for passordbytte og les den slik en bruker ville gjort, og spør deretter hvilken tjeneste som faktisk eier legitimasjonen. Siden er et skjema; identitetslageret er autoriteten. Hvis de to ikke er enige, møter brukeren et avvist passord, en tilbakestilling som ikke tilbakestiller noe, eller en suksessmelding som ikke endrer noe. Å følge flyten fra skjermen til backenden er den eneste måten å fange det.

Begynn med å klassifisere operasjonen: et vanlig bytte, en flyt for utløpt passord eller gjenoppretting etter et glemt passord.

Tre operasjoner, tre arbeidsflyter

Et vanlig bytte forutsetter at brukeren kjenner det gjeldende passordet og kan bevise det. En flyt for utløpt passord kan tillate en begrenset økt der bare byttet er tillatt. Gjenoppretting etter et glemt passord krever et helt annet identitetsbevis, og det kan delegeres til en identitetsleverandør i stedet for å håndteres ved VPN-gatewayen. Hver har sitt eget endepunkt, backend-støtte og øktregler, og ett skjema kan ikke betjene alle tre riktig.

I en føderert utrulling samler gatewayen kanskje ikke inn et nytt passord i det hele tatt. Kontroller om flyten omdirigerer til identitetsleverandøren, og om teksten på siden fortsatt beskriver et lokalt skjema.

Hvor policyen faktisk kommer fra

Spør identitetseieren om tillatt lengde, tegnsett og eventuelle gjeldende begrensninger, og skriv deretter instruksjoner som samsvarer. Å finne opp sammensetningsregler i hjelpeteksten, eller å love en aksept som backenden avviser, gir begge støttebilletter. NISTs veiledning for digital identitet heller mot klar veiledning og nyttig tilbakemelding i stedet for vilkårlige regler, mens organisasjonens faktiske policy fortsatt gjelder. En publikasjon er ikke bevis for at en bestemt katalog allerede oppfører seg slik.

Hold feilmeldinger nyttige uten å lekke hemmeligheter. En melding som gjengir et delvis skrevet passord, eller et skjermbilde i en billett som inneholder ett, gjør et støtteartefakt om til en eksponering av legitimasjon.

Formuleringer som passer backenden

Siden bør navngi arbeidsflyten i stedet for å beskrive policyen abstrakt. Si hvor byttet skjer, hvilket bevis som kreves, og hva som skjer med andre økter. Hvis byttet logger brukeren ut overalt, si det; hvis det lar andre enheter være aktive, si det også. En forvirret bruker som gjentar et vellykket bytte, er en støttekostnad som bedre formuleringer forhindrer.

Lokalisering kan endre tonen i instruksjonene; den kan ikke endre hva backenden godtar.

Test flyten, ikke siden

Bruk en tillatt testkonto og gå gjennom det dokumenterte byttet, en avvisningssak, saken med utløpt passord og den påfølgende påloggingen. Der MFA eller en føderert omdirigering er en del av den godkjente flyten, gå gjennom det også. En side som vises riktig, har verifisert presentasjonen og ingenting annet, fordi identitetstjenesten avgjør om legitimasjonsoperasjonen ble fullført.

Registrer resultatet av hver sak med kontoen som ble brukt og klokkeslettet. En flyt som fungerer én gang for en administrator og feiler for en vanlig bruker, er et vanlig utfall, og registreringen er det som gjør det synlig.

Oppdater deretter siden slik at den beskriver hva som faktisk skjedde. Det er hele oppgaven.