Cấu hình nhà cung cấp xác thực

Trong Ping64, nhà cung cấp xác thực dùng để cấu hình các tham số kết nối xác thực cho ứng dụng nghiệp vụ. Quản lý danh tính hỗ trợ xác thực ứng dụng qua OAuth 2.0 / OpenID Connect (OIDC). Sau khi cấu hình nhà cung cấp, cần liên kết với ứng dụng và hoàn tất cấu hình, kiểm tra ở phía ứng dụng nghiệp vụ.

Nhà cung cấp xác thực và nguồn danh tính thư mục có mục đích khác nhau: nguồn danh tính kết nối hoặc quản lý dữ liệu danh tính, còn nhà cung cấp phục vụ kết nối xác thực ứng dụng. Lưu nhà cung cấp không có nghĩa là ứng dụng đã tích hợp xong hoặc mọi người dùng đều được truy cập.

Các nhãn giao diện in đậm trong bài này dựa trên giao diện tiếng Anh. Nhãn hiển thị có thể khác khi sử dụng ngôn ngữ khác.

Nếu ứng dụng mục tiêu đã có nhà cung cấp phù hợp, hãy kiểm tra và giữ liên kết đó. Nếu chưa liên kết, có thể chọn nhà cung cấp hiện có được cấu hình phù hợp và chưa bị ứng dụng khác sử dụng. Một nhà cung cấp không thể đồng thời liên kết với nhiều ứng dụng; nếu đã bị dùng, hãy chuẩn bị nhà cung cấp phù hợp khác và không gỡ liên kết cũ khi chưa đánh giá tác động. Kiểm tra phụ thuộc ứng dụng và phương án khôi phục trước khi đổi cấu hình xác thực.

Chuẩn bị

• Sử dụng tài khoản quản trị có quyền xem và cấu hình quản lý danh tính. Xóa nhà cung cấp cần quyền thao tác tương ứng.
• Xác nhận với người phụ trách ứng dụng về loại máy khách, địa chỉ gọi lại khi đăng nhập, địa chỉ chuyển hướng sau đăng xuất, phạm vi cần thiết và yêu cầu định danh người dùng.
• Chuẩn bị khóa ký khả dụng trong Certificates, ứng dụng thử nghiệm và các tài khoản thử nghiệm có và không có quyền truy cập.
• Client Secret là thông tin xác thực nhạy cảm. Lưu giữ và chuyển giao qua kênh an toàn được tổ chức chấp thuận; không ghi vào phiếu hỗ trợ thông thường, ảnh chụp màn hình hoặc tài liệu công khai.

Tạo nhà cung cấp

1. IAM > Authentication Configuration > Authentication Providers: Trong bảng điều khiển, chuyển sang quản lý danh tính, mở Authentication Providers trong Authentication Configuration, rồi chọn Create.
2. Tại Basic Information, nhập tên và mô tả nếu cần. Tên là bắt buộc.
3. Tại Protocol Settings, chọn Client Type: Confidential phù hợp với ứng dụng có thể lưu Client Secret an toàn; Public phù hợp với máy khách không thể lưu an toàn Secret dùng chung. Khi tạo mới, Confidential được chọn mặc định; hãy xác nhận lựa chọn theo phương thức tích hợp thực tế của ứng dụng.
4. Kiểm tra Client ID được tạo tự động. Máy khách bảo mật cũng hiển thị Client Secret. Trước khi tạo lại một trong hai giá trị, đánh giá ảnh hưởng đến kết nối ứng dụng và chuyển giao thông tin xác thực mới bằng kênh an toàn.
5. Nhập ít nhất một và tối đa mười mục Redirect URI. Mỗi địa chỉ phải bắt đầu bằng http:// hoặc https:// và trùng với địa chỉ gọi lại đăng nhập mà ứng dụng thực sự sử dụng. Nếu cần, thêm tối đa mười mục Logout Redirect URI.
6. Chọn Signing Key khả dụng. Trong Advanced Protocol Settings, chọn Scope, Subject Mode và Issuer Mode, rồi xác nhận với người phụ trách ứng dụng. Scope giới hạn phạm vi thông tin danh tính ứng dụng yêu cầu; Subject Mode ảnh hưởng đến định danh người dùng mà ứng dụng nhận được. Không cấp các Scope không cần thiết.
7. Lưu và kiểm tra thông báo thành công hoặc thất bại. Việc trở về danh sách không nhất thiết chứng minh đã lưu thành công; hãy mở lại nhà cung cấp để kiểm tra tên, Client ID, địa chỉ gọi lại và các cấu hình khác.

Đăng ký địa chỉ gọi lại đăng nhập đầy đủ mà ứng dụng thực sự sử dụng, gồm đường dẫn, dấu gạch chéo cuối và tham số truy vấn. Dùng cùng địa chỉ khi cấp quyền và trao đổi mã cấp quyền; chỉ nhập tên miền là không đủ. Nếu ứng dụng yêu cầu chuyển hướng sau khi đăng xuất, trước tiên đăng ký địa chỉ đầy đủ tương ứng trong Logout Redirect URI. Địa chỉ chưa đăng ký sẽ bị từ chối. Nếu không dùng chuyển hướng sau đăng xuất thì không cần thêm địa chỉ.

Việc trang cấu hình chấp nhận địa chỉ http:// không có nghĩa địa chỉ đó phù hợp cho môi trường sản xuất hoặc lưu lượng mạng đã được bảo vệ. Đánh giá phương thức truyền và địa chỉ gọi lại theo yêu cầu bảo mật của tổ chức.

Chọn và kiểm tra phạm vi: Trang cung cấp openid, profile, email và offline_access. Lựa chọn tại đây quy định phạm vi ứng dụng được phép yêu cầu; ứng dụng vẫn phải thực sự yêu cầu phạm vi cần thiết khi đăng nhập. Yêu cầu phải có ít nhất một phạm vi và không được vượt quá phạm vi được phép. Với đăng nhập OIDC, hãy chọn openid theo yêu cầu tích hợp. Để lấy tên hoặc email qua thông tin người dùng, hãy xác nhận tương ứng profile hoặc email đã được cho phép và thực sự được yêu cầu. Thông tin email còn phụ thuộc việc tài khoản có địa chỉ email hay không. offline_access liên quan đến mã làm mới, nhưng chỉ chọn mục này không bảo đảm có thể làm mới: cấu hình lưu qua trang này không cho phép phương thức cấp bằng mã làm mới. Không dựa riêng vào thông tin khám phá hoặc việc nhận mã làm mới để kết luận lần làm mới sau sẽ thành công. Nếu nghiệp vụ cần duy trì đăng nhập, hãy thống nhất phương án khả dụng với người phụ trách ứng dụng và bộ phận hỗ trợ kỹ thuật, rồi kiểm tra hành vi sau khi mã hết hạn trước khi triển khai.

Liên kết và xác minh ứng dụng

Nếu nhà cung cấp hiện có đáp ứng yêu cầu và đã liên kết với ứng dụng đích, bỏ qua bước 1 và 2, kiểm tra từ bước 3 rồi tiếp tục xác minh. Chỉ thực hiện bước 1 và 2 khi cần tạo ứng dụng hoặc thay đổi liên kết. Trước khi thay đổi, đánh giá ảnh hưởng đến các ứng dụng và người dùng khác, đồng thời chuẩn bị phương án khôi phục.

1. Mở Applications trong Applications & Access, sau đó tạo hoặc chỉnh sửa ứng dụng.
2. Mở cửa sổ chọn tại trường nhà cung cấp trong cấu hình ứng dụng và chọn nhà cung cấp phù hợp và khả dụng. Hoàn tất các cài đặt bắt buộc khác rồi lưu. Cấu hình phạm vi truy cập theo nhu cầu sử dụng thực tế; chỉ liên kết nhà cung cấp không tự cấp quyền truy cập cho người dùng.
3. Trở lại Authentication Providers, chọn tên nhà cung cấp để mở chi tiết và kiểm tra ứng dụng liên kết, Client ID, địa chỉ gọi lại cùng thông tin cấu hình OpenID hiển thị.
4. Trước tiên kiểm tra tham số kết nối trong ứng dụng nghiệp vụ; chỉ khi chưa đáp ứng yêu cầu, người phụ trách ứng dụng mới điều chỉnh theo kế hoạch được phê duyệt. Dùng tài khoản thử nghiệm được kiểm soát để kiểm tra cả trường hợp được phép và không được phép truy cập, đồng thời kiểm tra chuyển hướng thực tế sau đăng nhập và đăng xuất.
5. Xác minh Scope được yêu cầu, định danh người dùng và kiểm tra chữ ký có đúng mong đợi. Đối chiếu Issuer Mode với tài liệu khám phá thực tế, mã thông báo và kết quả kiểm thử tích hợp; không chỉ dựa vào mô tả tùy chọn trên trang để xác định bên phát hành thực tế.
6. Xác nhận với người phụ trách rằng ứng dụng sử dụng luồng mã ủy quyền. Khi máy khách bảo mật dùng Secret, xác nhận qua kênh an toàn rằng cấu hình hai phía khớp nhau. Máy khách công khai phải hỗ trợ PKCE và sử dụng các tham số xác minh tương ứng khi yêu cầu và trao đổi mã ủy quyền; ưu tiên S256. Xác thực có thể thất bại nếu không hỗ trợ PKCE hoặc các tham số không khớp. Không chuyển sang máy khách bảo mật để bỏ qua hạn chế ứng dụng không thể lưu Secret an toàn.

Chỉnh sửa và xóa

Chọn Edit cho nhà cung cấp trong danh sách để thay đổi cấu hình. Nếu không tạo lại Secret khi chỉnh sửa, trang có thể hiển thị giá trị che; không dùng giá trị che làm Secret thực tế. Thay đổi Client ID, Secret, URI chuyển hướng, khóa ký hoặc chế độ định danh người dùng có thể ảnh hưởng đến ứng dụng đã kết nối. Trước khi thay đổi, sắp xếp thời gian bảo trì và phương án khôi phục; sau đó kiểm tra lại các ứng dụng liên quan.

Trước khi xóa, xác định phụ thuộc của ứng dụng và chuẩn bị phương án chuyển đổi. Xóa nhà cung cấp sẽ bỏ liên kết ứng dụng và ảnh hưởng đến thông tin xác thực liên quan, có thể khiến người dùng không tiếp tục được luồng xác thực tương ứng. Không giả định liên kết sẽ tự khôi phục sau khi xóa.

Xử lý sự cố

• Không tìm thấy nhà cung cấp: Tìm kiếm theo tên có thể bỏ sót mục hiện có. Xóa từ khóa và kiểm tra danh sách cùng quyền tài khoản.
• Lưu thất bại: Kiểm tra tên, địa chỉ gọi lại, khóa ký, Scope, các trường bắt buộc khác và thông báo trên trang. Trở về danh sách không chứng minh đã lưu thành công.
• Gọi lại đăng nhập thất bại: Đối chiếu đầy đủ địa chỉ gọi lại thực tế của ứng dụng với cấu hình nhà cung cấp, loại máy khách và tham số phía ứng dụng.
• Mã thông báo hoặc định danh người dùng không đúng mong đợi: Kiểm tra Scope, Subject, Issuer thực tế và khóa ký; dùng nhật ký ứng dụng để điều tra tích hợp.
• Ứng dụng không đăng nhập được sau thay đổi: Kiểm tra liên kết, Client ID, Secret, khóa ký và trạng thái ứng dụng, rồi thực hiện phương án khôi phục đã được phê duyệt.