Trang đổi mật khẩu VPN: khớp với kho định danh

Mở trang đổi mật khẩu và đọc như một người dùng sẽ đọc, sau đó hỏi dịch vụ nào thực sự sở hữu thông tin đăng nhập. Trang là biểu mẫu; kho định danh là thẩm quyền. Nếu hai bên không khớp, người dùng gặp mật khẩu bị từ chối, một lần đặt lại không đặt lại gì, hoặc thông báo thành công không thay đổi gì. Đi theo luồng từ màn hình đến backend là cách duy nhất để bắt được điều đó.

Bắt đầu bằng việc phân loại thao tác: đổi thông thường, luồng mật khẩu hết hạn, hoặc khôi phục sau khi quên mật khẩu.

Ba thao tác, ba quy trình

Đổi thông thường giả định người dùng biết mật khẩu hiện tại và có thể chứng minh điều đó. Luồng mật khẩu hết hạn có thể cho phép một phiên hạn chế trong đó chỉ được phép đổi. Khôi phục sau khi quên mật khẩu cần một bằng chứng định danh hoàn toàn khác, và có thể được giao cho nhà cung cấp định danh thay vì xử lý tại cổng VPN. Mỗi loại có điểm cuối, hỗ trợ backend và quy tắc phiên riêng, và một biểu mẫu không thể phục vụ đúng cả ba.

Trong triển khai liên hợp, cổng có thể không thu thập mật khẩu mới nào cả. Kiểm tra xem luồng có chuyển hướng đến nhà cung cấp định danh không và văn bản trang có còn mô tả biểu mẫu cục bộ không.

Chính sách thực sự đến từ đâu

Hỏi chủ sở hữu định danh về độ dài được phép, bộ ký tự và mọi hạn chế áp dụng, rồi viết hướng dẫn khớp với điều đó. Bịa ra quy tắc thành phần trong văn bản trợ giúp, hoặc hứa hẹn một sự chấp nhận mà backend từ chối, cả hai đều tạo ra phiếu hỗ trợ. Hướng dẫn của NIST về định danh số nghiêng về chỉ dẫn rõ ràng và phản hồi hữu ích thay vì các quy tắc tùy tiện, trong khi chính sách thực tế của tổ chức vẫn chi phối. Một ấn phẩm không phải là bằng chứng rằng một thư mục cụ thể đã hành xử như vậy.

Giữ thông báo lỗi hữu ích mà không làm lộ bí mật. Một thông báo lặp lại mật khẩu đã gõ một phần, hoặc ảnh chụp màn hình trong phiếu có chứa nó, biến một tạo tác hỗ trợ thành sự phơi bày thông tin đăng nhập.

Cách diễn đạt khớp với backend

Trang nên gọi tên quy trình thay vì mô tả chính sách một cách trừu tượng. Nói rõ việc đổi diễn ra ở đâu, cần bằng chứng gì và điều gì xảy ra với các phiên khác. Nếu việc đổi đăng xuất người dùng ở mọi nơi, hãy nói vậy; nếu nó để các thiết bị khác hoạt động, cũng hãy nói vậy. Một người dùng bối rối lặp lại một lần đổi thành công là chi phí hỗ trợ mà cách diễn đạt tốt hơn ngăn được.

Bản địa hóa có thể thay đổi giọng điệu của hướng dẫn; nó không thể thay đổi điều backend chấp nhận.

Kiểm thử luồng, không phải trang

Dùng một tài khoản thử nghiệm được phép và đi qua lần đổi đã ghi tài liệu, trường hợp từ chối, trường hợp mật khẩu hết hạn và lần đăng nhập sau đó. Ở đâu MFA hoặc chuyển hướng liên hợp là một phần của luồng đã được phê duyệt, hãy đi qua cả điều đó. Một trang hiển thị đúng đã xác minh phần trình bày và không gì khác, vì dịch vụ định danh quyết định liệu thao tác với thông tin đăng nhập đã hoàn tất.

Ghi lại kết quả của từng trường hợp cùng tài khoản đã dùng và thời gian. Một luồng hoạt động một lần cho quản trị viên và thất bại cho người dùng thông thường là kết quả phổ biến, và bản ghi là thứ khiến nó hiển hiện.

Sau đó cập nhật trang để mô tả điều thực sự đã xảy ra. Đó là toàn bộ công việc.