Danh tính

Portal không bao giờ tự kiểm tra mật khẩu công ty. Keycloak là nhà cung cấp danh tính trung tâm, đứng giữa portal và danh bạ của công ty bạn (Entra ID hoặc Okta). SCIMCấp tài khoản qua SCIMSCIM provisioningChuẩn mà nhà cung cấp danh tính dùng để tự động tạo, cập nhật và xoá tài khoản portal, để người nghỉ việc mất quyền truy cập.Mở trong Thuật ngữ giữ danh sách người dùng trong portal khớp với danh bạ đó.

Quy tắc chính

1. Keycloak là nhà cung cấp danh tính duy nhất mà portal làm việc cùng. Keycloak kết nối Entra ID hoặc Okta để đăng nhập một lầnĐăng nhập một lần (SSO)Single sign-on (SSO)Đăng nhập một lần bằng tài khoản công ty, như Entra ID hoặc Okta. Portal không bao giờ thấy mật khẩu của bạn.Mở trong Thuật ngữ.
2. Ứng dụng chỉ dùng OIDC. Không thành phần nào của portal nói chuyện trực tiếp với Entra ID hay Okta.
3. Token nằm ở máy chủ. Backend giữ token; trình duyệt chỉ giữ một cookie phiên.
4. SCIM cấp tài khoản cho mọi người. Nhà cung cấp của bạn đẩy người mới vào, thay đổi và người nghỉ việc sang portal, nơi đóng vai trò máy chủ SCIM.
5. Mỗi yêu cầu đều được kiểm tra. Chỗ của mỗi người trong tổ chức được đọc lại ở mọi yêu cầu, nên lệnh tạm khóa có hiệu lực ngay ở yêu cầu tiếp theo.

Các thành phần

Mỗi bản triển khai chỉ có một tổ chứcTổ chứcOrganisationKhông gian của công ty bạn trong portal. Mỗi bản triển khai chạy một tổ chức, trong chính tài khoản AWS của bạn.Mở trong Thuật ngữ, nên chỉ có một đường đăng nhập và một nhà cung cấp của công ty đứng sau.

Thành phần	Vai trò
Trình duyệt	Chỉ giữ cookie phiên, không giữ gì khác
Backend của portal	Giữ token, kiểm tra mọi yêu cầu và làm máy chủ SCIM
Keycloak	Nhà cung cấp danh tính trung tâm; hiển thị các màn hình đăng nhập và kết nối nhà cung cấp của bạn
Entra ID hoặc Okta	Danh bạ công ty; xác thực người dùng và đẩy thay đổi qua SCIM

Trường thông tin nào do nhà cung cấp quản lý, trường nào do portal quản lý, tùy vào chế độ danh bạ. Xem Phòng ban › Ai sở hữu trường nào và Phòng ban › Chế độ thư mục.

Ba trang về danh tính

Xác thực yêu cầu

Hai lớp kiểm tra chung chạy trên mọi route: trước là kiểm tra phiên, sau là kiểm tra vai trò. Mọi route đều đóng, trừ khi được đánh dấu công khai.

Lớp kiểm tra phiên đi qua các bước sau theo thứ tự:

1. Có cookie phiên không? Trình duyệt luôn gửi kèm cookie. Yêu cầu không có cookie đi theo đường bearer: token được xác minh và đọc các claim.
2. Cookie còn hợp lệ không? Nếu không, kết quả là 401. Không có đường lùi sang bearer.
3. Token sắp hết hạn? Token được làm mới trước khi yêu cầu chạy tiếp.
4. Phương thức có thay đổi dữ liệu? Yêu cầu thay đổi dữ liệu cần header CSRF khớp với phiên.
5. Có chỗ trong tổ chức không? Không có chỗ thì trả 401.
6. Bị tạm khóa? Người bị vô hiệu hóa ở nhà cung cấp hoặc bị tạm khóa trong portal nhận 403 access_revoked.
7. Qua được. Lớp kiểm tra vai trò sau đó xét các quyền hạnQuyền hạnCapabilityQuyền làm một loại việc, như đặt ngân sách hay đọc nhật ký kiểm toán. Vai trò là cách duy nhất để có quyền hạn.Mở trong Thuật ngữ mà route yêu cầu.

Tình huống	Kết quả
Không có cookie phiên	Đường bearer: xác minh token và đọc các claim
Cookie không còn hợp lệ	401, không lùi sang đường bearer
Token sắp hết hạn	Làm mới dưới khóa
Phương thức thay đổi dữ liệu	Cần header CSRF khớp với phiên
Không có chỗ trong tổ chức	401
Bị vô hiệu hóa ở nhà cung cấp hoặc bị tạm khóa trong portal	403 access_revoked ở yêu cầu tiếp theo; đăng nhập cũng bị từ chối vì cùng lý do
Token thiếu claim	401, không bao giờ là 500
Không truy cập được khóa ký token	503

Ngữ cảnh của trình duyệt được tính một lần, lúc đăng nhập hoặc làm mới. Lời gọi từ máy được xác minh ở mọi yêu cầu. Dù theo đường nào, chỗ của người dùng cũng được đọc mới ở mọi yêu cầu, không có bộ nhớ đệm.

Vì sao lại như vậy

Bên trong hệ thống

Liên quan