VPN-pagina voor wachtwoordwijziging: afstemmen op de identiteitsopslag

Open de pagina voor wachtwoordwijziging en lees hem zoals een gebruiker dat zou doen, en vraag dan welke dienst de inloggegevens werkelijk bezit. De pagina is een formulier; de identiteitsopslag is de autoriteit. Als de twee niet overeenkomen, krijgt de gebruiker een geweigerd wachtwoord, een reset die niets reset, of een succesmelding die niets verandert. De stroom van het scherm naar de backend doorlopen is de enige manier om dat te vangen.

Begin met het classificeren van de bewerking: een normale wijziging, een stroom voor verlopen wachtwoorden of herstel na een vergeten wachtwoord.

Drie bewerkingen, drie werkstromen

Een normale wijziging veronderstelt dat de gebruiker het huidige wachtwoord kent en kan bewijzen. Een stroom voor verlopen wachtwoorden kan een beperkte sessie toestaan waarin alleen de wijziging is toegestaan. Herstel na een vergeten wachtwoord vereist een heel ander identiteitsbewijs, en het kan worden gedelegeerd aan een identiteitsprovider in plaats van te worden afgehandeld bij de VPN-gateway. Elk heeft zijn eigen eindpunt, backend-ondersteuning en sessieregels, en één formulier kan niet alle drie correct bedienen.

Bij een federatieve implementatie verzamelt de gateway misschien helemaal geen nieuw wachtwoord. Controleer of de stroom doorverwijst naar de identiteitsprovider en of de tekst van de pagina nog steeds een lokaal formulier beschrijft.

Waar het beleid werkelijk vandaan komt

Vraag de identiteitseigenaar naar de toegestane lengte, de tekenset en eventuele toepasselijke beperkingen, en schrijf vervolgens instructies die daarbij passen. Samenstellingsregels verzinnen in de helptekst, of acceptatie beloven die de backend weigert, levert beide supporttickets op. De NIST-richtlijnen voor digitale identiteit neigen naar duidelijke begeleiding en nuttige feedback in plaats van willekeurige regels, terwijl het werkelijke beleid van de organisatie nog steeds geldt. Een publicatie is geen bewijs dat een bepaalde directory zich al zo gedraagt.

Houd foutmeldingen nuttig zonder geheimen te lekken. Een bericht dat een gedeeltelijk getypt wachtwoord herhaalt, of een schermafbeelding in een ticket die er een bevat, verandert een supportartefact in een blootstelling van inloggegevens.

Formulering die bij de backend past

De pagina moet de werkstroom benoemen in plaats van het beleid abstract te beschrijven. Zeg waar de wijziging plaatsvindt, welk bewijs nodig is en wat er met andere sessies gebeurt. Als de wijziging de gebruiker overal uitlogt, zeg dat dan; als andere apparaten actief blijven, zeg dat ook. Een verwarde gebruiker die een geslaagde wijziging herhaalt, is een supportkostenpost die betere formulering voorkomt.

Lokalisatie kan de toon van de instructies veranderen; zij kan niet veranderen wat de backend accepteert.

Test de stroom, niet de pagina

Gebruik een toegestaan testaccount en doorloop de gedocumenteerde wijziging, een weigeringsgeval, het geval van het verlopen wachtwoord en de daaropvolgende aanmelding. Waar MFA of een federatieve doorverwijzing deel uitmaakt van de goedgekeurde stroom, doorloop dat ook. Een pagina die correct wordt weergegeven, heeft de presentatie geverifieerd en niets anders, omdat de identiteitsdienst beslist of de bewerking met de inloggegevens is voltooid.

Noteer het resultaat van elk geval met het gebruikte account en de tijd. Een stroom die één keer werkt voor een beheerder en faalt voor een normale gebruiker is een veelvoorkomende uitkomst, en het verslag is wat dat zichtbaar maakt.

Werk daarna de pagina bij om te beschrijven wat er werkelijk is gebeurd. Dat is de hele taak.