Pagina de schimbare a parolei VPN: aliniere la depozitul de identități
Formularul nu este autoritatea. Aflați ce depozit deține parola, scrieți instrucțiuni conforme cu politica acestuia și testați căile de schimbare, respingere și resetare.
Deschideți pagina de schimbare a parolei și citiți-o așa cum ar face-o un utilizator, apoi întrebați ce serviciu deține de fapt acreditarea. Pagina este un formular; depozitul de identități este autoritatea. Dacă cele două nu sunt de acord, utilizatorul întâlnește o parolă respinsă, o resetare care nu resetează nimic sau un mesaj de succes care nu schimbă nimic. Parcurgerea fluxului de la ecran la backend este singura cale de a prinde asta.
Începeți prin a clasifica operațiunea: o schimbare normală, un flux pentru parolă expirată sau o recuperare după o parolă uitată.
Trei operațiuni, trei fluxuri de lucru
O schimbare normală presupune că utilizatorul cunoaște parola curentă și o poate demonstra. Un flux pentru parolă expirată poate permite o sesiune limitată în care este permisă doar schimbarea. Recuperarea după o parolă uitată necesită o dovadă de identitate complet diferită și poate fi delegată unui furnizor de identitate în loc să fie tratată la gateway-ul VPN. Fiecare are propriul punct final, suport backend și reguli de sesiune, iar un singur formular nu poate deservi corect toate trei.
Într-o implementare federată, gateway-ul poate să nu colecteze deloc o parolă nouă. Verificați dacă fluxul redirecționează către furnizorul de identitate și dacă textul paginii mai descrie un formular local.
De unde vine de fapt politica
Întrebați proprietarul identității despre lungimea permisă, setul de caractere și orice restricții aplicabile, apoi scrieți instrucțiuni care să corespundă. Inventarea unor reguli de compoziție în textul de ajutor sau promiterea unei acceptări pe care backend-ul o refuză produc ambele tichete de suport. Ghidul NIST privind identitatea digitală înclină spre îndrumări clare și feedback util în locul unor reguli arbitrare, în timp ce politica reală a organizației rămâne în continuare autoritară. O publicație nu este dovada că un anumit director se comportă deja astfel.
Păstrați mesajele de eroare utile fără a scurge secrete. Un mesaj care repetă o parolă tastată parțial, sau o captură de ecran într-un tichet care conține una, transformă un artefact de suport într-o expunere de acreditări.
Formulare aliniată la backend
Pagina ar trebui să numească fluxul de lucru în loc să descrie politica în mod abstract. Spuneți unde are loc schimbarea, ce dovadă este necesară și ce se întâmplă cu celelalte sesiuni. Dacă schimbarea deconectează utilizatorul peste tot, spuneți-o; dacă lasă alte dispozitive active, spuneți și asta. Un utilizator confuz care repetă o schimbare reușită este un cost de suport pe care o formulare mai bună îl evită.
Localizarea poate schimba tonul instrucțiunilor; nu poate schimba ce acceptă backend-ul.
Testați fluxul, nu pagina
Folosiți un cont de test permis și parcurgeți schimbarea documentată, un caz de respingere, cazul parolei expirate și autentificarea ulterioară. Acolo unde MFA sau o redirecționare federată fac parte din fluxul aprobat, parcurgeți și aceasta. O pagină care se afișează corect a verificat prezentarea și nimic altceva, pentru că serviciul de identitate decide dacă operațiunea cu acreditările s-a încheiat.
Înregistrați rezultatul fiecărui caz cu contul folosit și ora. Un flux care funcționează o dată pentru un administrator și eșuează pentru un utilizator obișnuit este un rezultat frecvent, iar înregistrarea este cea care îl face vizibil.
Apoi actualizați pagina pentru a descrie ce s-a întâmplat de fapt. Acesta este întregul task.