Stránka pro změnu hesla VPN: sladění s úložištěm identit

Otevřete stránku pro změnu hesla a přečtěte si ji tak, jak by ji četl uživatel, a poté se zeptejte, která služba skutečně vlastní přihlašovací údaj. Stránka je formulář; úložiště identit je autorita. Pokud se obě neshodují, uživatel narazí na odmítnuté heslo, reset, který nic neresetuje, nebo zprávu o úspěchu, která nic nezmění. Projít tok od obrazovky k backendu je jediný způsob, jak to odhalit.

Začněte klasifikací operace: běžná změna, tok s expirovaným heslem nebo obnova po zapomenutém heslu.

Tři operace, tři pracovní postupy

Běžná změna předpokládá, že uživatel zná aktuální heslo a dokáže to. Tok s expirovaným heslem může povolit omezenou relaci, ve které je povolena pouze změna. Obnova po zapomenutém heslu vyžaduje zcela jiný důkaz identity a může být delegována poskytovateli identity, místo aby byla řešena na bráně VPN. Každá má svůj koncový bod, podporu backendu a pravidla relace a jeden formulář nemůže správně obsloužit všechny tři.

Ve federovaném nasazení brána nemusí nové heslo vůbec sbírat. Zkontrolujte, zda tok přesměrovává k poskytovateli identity a zda text stránky stále popisuje místní formulář.

Odkud zásady skutečně pocházejí

Zeptejte se vlastníka identity na povolenou délku, znakovou sadu a případná omezení a poté napište pokyny, které tomu odpovídají. Vymýšlení pravidel složení v textu nápovědy nebo slibování přijetí, které backend odmítá, obojí vytváří tikety podpory. Pokyny NIST pro digitální identitu se kloní k jasnému vedení a užitečné zpětné vazbě namísto svévolných pravidel, přičemž skutečná politika organizace stále platí. Publikace není důkazem, že konkrétní adresář se už tak chová.

Udržujte chybové zprávy užitečné, aniž byste unikali tajemství. Zpráva, která opakuje částečně napsané heslo, nebo snímek obrazovky v tiketu, který jej obsahuje, promění artefakt podpory v odhalení přihlašovacích údajů.

Formulace odpovídající backendu

Stránka by měla pojmenovat pracovní postup, nikoli popisovat zásady abstraktně. Řekněte, kde ke změně dochází, jaký důkaz je vyžadován a co se stane s ostatními relacemi. Pokud změna odhlásí uživatele všude, řekněte to; pokud ponechá jiná zařízení aktivní, řekněte to také. Zmatený uživatel, který opakuje úspěšnou změnu, je náklad na podporu, kterému lepší formulace zabrání.

Lokalizace může změnit tón pokynů; nemůže změnit, co backend přijímá.

Testujte tok, ne stránku

Použijte povolený testovací účet a projděte zdokumentovanou změnu, případ odmítnutí, případ expirovaného hesla a následné přihlášení. Kde je MFA nebo federované přesměrování součástí schváleného toku, projděte i to. Stránka, která se vykresluje správně, ověřila prezentaci a nic jiného, protože o dokončení operace s přihlašovacím údajem rozhoduje služba identity.

Zaznamenejte výsledek každého případu s použitým účtem a časem. Tok, který jednou funguje pro správce a selhává pro běžného uživatele, je častý výsledek a záznam je to, co jej činí viditelným.

Poté stránku aktualizujte, aby popisovala, co se skutečně stalo. To je celý úkol.