Сторінка зміни пароля VPN: узгодження зі сховищем ідентичностей

Відкрийте сторінку зміни пароля і прочитайте її так, як прочитав би користувач, потім запитайте, яка служба насправді володіє обліковими даними. Сторінка — це форма; сховище ідентичностей — це орган. Якщо вони розходяться, користувач стикається з відхиленим паролем, скиданням, яке нічого не скидає, або повідомленням про успіх, яке нічого не змінює. Пройти шлях від екрана до бекенду — єдиний спосіб це виявити.

Почніть із класифікації операції: звичайна зміна, потік простроченого пароля або відновлення після забутого пароля.

Три операції, три робочі процеси

Звичайна зміна передбачає, що користувач знає поточний пароль і може це довести. Потік простроченого пароля може дозволяти обмежений сеанс, у якому дозволено лише зміну. Відновлення після забутого пароля потребує зовсім іншого підтвердження особи і може бути делеговане постачальнику ідентичності, а не оброблятися на шлюзі VPN. Кожна має власну кінцеву точку, підтримку в бекенді та правила сеансу, і одна форма не може правильно обслужити всі три.

У федеративному розгортанні шлюз може взагалі не збирати новий пароль. Перевірте, чи перенаправляє потік до постачальника ідентичності і чи текст сторінки досі описує локальну форму.

Звідки політика насправді береться

Запитайте власника ідентичності про допустиму довжину, набір символів і будь-які застосовні обмеження, потім напишіть відповідні інструкції. Вигадування правил складу в тексті довідки або обіцянка приймання, яке бекенд відхиляє, однаково породжують звернення до підтримки. Настанови NIST щодо цифрової ідентичності схиляються до чітких вказівок і корисної взаємодії замість довільних правил, а реальна політика організації досі головує. Публікація не є доказом того, що конкретний каталог уже поводиться саме так.

Зберігайте повідомлення про помилки корисними, не розкриваючи таємниць. Повідомлення, що повторює частково введений пароль, або знімок екрана в заявці, що його містить, перетворюють артефакт підтримки на розкриття облікових даних.

Формулювання, що відповідають бекенду

Сторінка має називати робочий процес, а не описувати політику абстрактно. Скажіть, де відбувається зміна, яке підтвердження потрібне і що відбувається з іншими сеансами. Якщо зміна завершує сеанс користувача всюди, скажіть це; якщо інші пристрої залишаються активними, скажіть і це. Заплутаний користувач, який повторює успішну зміну, — це витрати на підтримку, яких запобігає краще формулювання.

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

Перевіряйте процес, а не сторінку

Використовуйте дозволений тестовий обліковий запис і пройдіть задокументовану зміну, випадок відхилення, випадок простроченого пароля та наступний вхід. Там, де MFA або федеративне перенаправлення є частиною затвердженого процесу, пройдіть і це. Сторінка, яка відображається правильно, перевірила подання і нічого більше, оскільки саме служба ідентичності вирішує, чи завершено операцію з обліковими даними.

Записуйте результат кожного випадку разом з використаним обліковим записом і часом. Процес, який один раз працює для адміністратора і не працює для звичайного користувача, є частим результатом, і саме запис робить це видимим.

Потім оновіть сторінку, щоб описати, що сталося насправді. Це і є все завдання.