Страница за смяна на парола за VPN: съответствие с хранилището на идентичности

Отворете страницата за смяна на парола и я прочетете така, както би я прочел потребител, след което попитайте коя услуга всъщност притежава идентификационните данни. Страницата е формуляр; хранилището на идентичности е органът. Ако двете не съвпадат, потребителят среща отказана парола, нулиране, което не нулира нищо, или съобщение за успех, което не променя нищо. Проследяването на потока от екрана до бекенда е единственият начин да се хване това.

Започнете с класифициране на операцията: нормална смяна, поток за изтекла парола или възстановяване след забравена парола.

Три операции, три работни потока

Нормалната смяна предполага, че потребителят знае текущата парола и може да го докаже. Потокът за изтекла парола може да разреши ограничена сесия, в която е разрешена само смяната. Възстановяването след забравена парола изисква съвсем различно доказателство за самоличност и може да бъде делегирано на доставчик на идентичност, вместо да се обработва на VPN шлюза. Всяка има свой краен адрес, поддръжка в бекенда и правила за сесията, и един формуляр не може да обслужва и трите правилно.

При федеративно внедряване шлюзът може изобщо да не събира нова парола. Проверете дали потокът пренасочва към доставчика на идентичност и дали текстът на страницата все още описва локален формуляр.

Откъде всъщност идва политиката

Попитайте собственика на идентичността за разрешената дължина, набор от знаци и всички приложими ограничения, след което напишете инструкции, които им съответстват. Измислянето на правила за състав в помощния текст или обещаването на приемане, което бекендът отказва, и двете водят до тикети за поддръжка. Насоките на NIST за цифрова идентичност клонят към ясни указания и полезна обратна връзка, вместо произволни правила, докато реалната политика на организацията все още е определяща. Публикацията не е доказателство, че определен каталог вече се държи по този начин.

Пазете съобщенията за грешки полезни, без да издавате тайни. Съобщение, което повтаря частично въведена парола, или екранна снимка в тикет, съдържаща такава, превръща артефакт за поддръжка в разкриване на идентификационни данни.

Формулировки, съответстващи на бекенда

Страницата трябва да назовава работния поток, вместо да описва политиката абстрактно. Кажете къде се извършва смяната, какво доказателство се изисква и какво се случва с другите сесии. Ако смяната изписва потребителя навсякъде, кажете го; ако оставя други устройства активни, кажете и това. Объркан потребител, който повтаря успешна смяна, е разход за поддръжка, който по-добрата формулировка предотвратява.

Локализацията може да промени тона на инструкциите; тя не може да промени това, което бекендът приема.

Тествайте потока, не страницата

Използвайте разрешен тестов акаунт и преминете документираната смяна, случай на отказ, случая с изтекла парола и последващото влизане. Когато MFA или федеративно пренасочване е част от одобрения поток, преминете и него. Страница, която се изобразява правилно, е проверила представянето и нищо друго, защото услугата за идентичност решава дали операцията с идентификационните данни е завършена.

Записвайте резултата от всеки случай с използвания акаунт и часа. Поток, който работи веднъж за администратор и се проваля за обикновен потребител, е често срещан резултат и записът е това, което го прави видим.

След това актуализирайте страницата, за да опишете какво действително се е случило. Това е цялата задача.