VPN-sida för lösenordsbyte: stäm av mot identitetslagret

Öppna sidan för lösenordsbyte och läs den som en användare skulle göra, och fråga sedan vilken tjänst som faktiskt äger inloggningsuppgifterna. Sidan är ett formulär; identitetslagret är auktoriteten. Om de två inte stämmer överens möter användaren ett avvisat lösenord, en återställning som inte återställer något, eller ett framgångsmeddelande som inte ändrar något. Att följa flödet från skärmen till backenden är det enda sättet att fånga det.

Börja med att klassificera åtgärden: ett vanligt byte, ett flöde för utgånget lösenord eller en återställning efter ett glömt lösenord.

Tre åtgärder, tre arbetsflöden

Ett vanligt byte förutsätter att användaren känner till det aktuella lösenordet och kan bevisa det. Ett flöde för utgånget lösenord kan tillåta en begränsad session där bara bytet är tillåtet. Återställning efter ett glömt lösenord kräver ett helt annat identitetsbevis, och det kan delegeras till en identitetsleverantör i stället för att hanteras vid VPN-gatewayen. Varje har sin egen slutpunkt, backend-stöd och sessionsregler, och ett formulär kan inte betjäna alla tre korrekt.

I en federerad distribution samlar gatewayen kanske inte in något nytt lösenord alls. Kontrollera om flödet omdirigerar till identitetsleverantören och om sidans text fortfarande beskriver ett lokalt formulär.

Varifrån policyn faktiskt kommer

Fråga identitetsägaren om tillåten längd, teckenuppsättning och eventuella tillämpliga begränsningar, och skriv sedan instruktioner som matchar. Att hitta på sammansättningsregler i hjälptexten, eller att lova ett godkännande som backenden avvisar, ger båda supportärenden. NIST:s riktlinjer för digital identitet lutar mot tydlig vägledning och användbar återkoppling i stället för godtyckliga regler, medan organisationens faktiska policy fortfarande gäller. En publikation är inte bevis för att en viss katalog redan beter sig så.

Håll felmeddelanden användbara utan att läcka hemligheter. Ett meddelande som upprepar ett delvis skrivet lösenord, eller en skärmbild i ett ärende som innehåller ett, förvandlar en supportartefakt till ett röjande av inloggningsuppgifter.

Formuleringar som matchar backenden

Sidan bör namnge arbetsflödet i stället för att beskriva policyn abstrakt. Ange var bytet sker, vilket bevis som krävs och vad som händer med andra sessioner. Om bytet loggar ut användaren överallt, säg det; om det lämnar andra enheter aktiva, säg det också. En förvirrad användare som upprepar ett lyckat byte är en supportkostnad som bättre formuleringar förhindrar.

Lokalisering kan ändra tonen i instruktionerna; den kan inte ändra vad backenden accepterar.

Testa flödet, inte sidan

Använd ett tillåtet testkonto och gå igenom det dokumenterade bytet, ett avvisningsfall, fallet med utgånget lösenord och den efterföljande inloggningen. Där MFA eller en federerad omdirigering är en del av det godkända flödet, gå igenom det också. En sida som visas korrekt har verifierat presentationen och inget annat, eftersom identitetstjänsten avgör om inloggningsuppgiftsåtgärden slutfördes.

Registrera resultatet för varje fall med kontot som användes och tiden. Ett flöde som fungerar en gång för en administratör och misslyckas för en vanlig användare är ett vanligt utfall, och registreringen är det som gör det synligt.

Uppdatera sedan sidan så att den beskriver vad som faktiskt hände. Det är hela uppgiften.