Bỏ qua đến nội dung
AI Portal Docs
Trên trang này Một người được cấp tài khoản thế nào 1/8
Cách hoạt động Danh tính Cấp tài khoản qua SCIM

Cấp tài khoản qua SCIM

Cách Entra ID hoặc Okta đẩy người dùng và nhóm vào portal qua SCIM, dùng thông tin xác thực nào, mỗi lần ghi được xử lý ra sao, và thay đổi được gom thành các đợt đồng bộ thế nào.

Quản trị IT Vận hành ECV Kiến trúc sư Khái niệm 6 phút đọc

Nhà cung cấp danh tính của bạn đẩy thay đổi 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ữ thẳng đến portal, nơi đóng vai trò máy chủ SCIM. Người mới vào, thay đổi và người nghỉ việc đều đến danh bạ mà không ai phải nhập lại.

Quy tắc chính

  1. Nhà cung cấp đẩy sang; portal không bao giờ tự kéo về. Portal không thể yêu cầu một lần đồng bộ.
  2. Email đã có thì được nhận lại, không tạo trùng. Việc nhận lại không đụng đến các trường do portal quản lý.
  3. Người nghỉ việc mất quyền truy cập trước tiên. Khi thu hồi tài khoản, portal được ghi trước Keycloak.
  4. Thay đổi được gom thành các đợt đồng bộ. Các thay đổi cách nhau không quá mười phút được tính là một đợt.
  5. Mọi lần ghi qua SCIM đều được ghi nhật ký với tác nhân hệ thống.

Một người được cấp tài khoản thế nào

  1. Nhà cung cấp lấy access token

    Nhà cung cấp trình client identifier và secret tại token endpoint của portal, và nhận về một access token có hạn một giờ.

  2. Nhà cung cấp tạo người dùng

    Nhà cung cấp gọi các route SCIM của portal, dùng token đó làm bearer token.

  3. Portal nhận lại hoặc tạo mới

    • Email đã có trong danh bạ: portal nhận lại dòng hiện có.
    • Người mới: portal tạo tài khoản Keycloak trước, rồi ghi dòng người dùng theo Keycloak id.

  4. Portal ghi một sự kiện quản trị

    Mọi lần ghi qua SCIM đều ghi một sự kiện quản trị với tác nhân hệ thống vào nhật ký kiểm traNhật ký kiểm toánAudit logBản ghi ai đã làm gì: mọi lệnh gọi mô hình kèm chi phí và phòng ban, cùng các thay đổi quản trị và phê duyệt.Mở trong Thuật ngữ.

  5. Portal trả lời nhà cung cấp

    Nhà cung cấp nhận về một phản hồi SCIM chuẩn.

Thông tin xác thực của connector

Tổ chức của bạn giữ một thông tin xác thực cho việc cấp tài khoản. Chọn phương thức mới sẽ thay thế thông tin cũ.

Phương thứcChi tiết
OAuth (mặc định)Portal tạo client identifier và secret, chỉ dùng tại một token endpoint mang tên tổ chức của bạn. Các yêu cầu danh bạ mang access token hết hạn một giờ sau khi cấp; connector tự gia hạn. Microsoft đánh dấu bearer token dài hạn là không được hỗ trợ cho các ứng dụng tạo từ nay về sau
Secret dài hạnTrình trực tiếp. Dành cho connector đang chạy sẵn với loại này, hoặc nhà cung cấp không hỗ trợ cách nào khác
  • Secret chỉ hiện một lần và chỉ được lưu dưới dạng digest. Secret bị mất thì được thay, và việc thay sẽ chặn connector đang giữ secret cũ.
  • Thay thông tin xác thực sẽ thu hồi ngay mọi access token được cấp dưới nó.
  • Sửa nhà cung cấp về sau không ảnh hưởng đến thông tin xác thực. Biểu mẫu nhà cung cấp là nơi sửa tên miền.
  • Secret bị từ chối trả về 401. Đây là trạng thái duy nhất mà lịch sử đồng bộ không ghi lại.
  • Mọi lời từ chối, tại token endpoint cũng như tại các route danh bạ, đều là cùng một câu trả lời không kèm chi tiết.
  • Nhà cung cấp đã đăng ký luôn có thông tin xác thực, vì danh bạ do nhà cung cấp làm chủ (chế độ IDP) bị khóa bảy thao tác ghi danh bạ, trong đó có lời mời.

Quy tắc ghi

Thao tácQuy tắc
Thứ tựTạo mới gọi Keycloak trước. Thu hồi tài khoản ghi portal trước, nên nếu Keycloak lỗi thì quyền truy cập đã bị chặn sẵn
Tạo, email đã cóNhận lại dòng đó và giữ nguyên phòng ban, vai trò trong tổ chức và trạng thái lời mời
Tạo với active: falseTài khoản được tạo ở trạng thái vô hiệu hóa, không bao giờ tạo rồi mới vô hiệu hóa
Delete trên UsersChỉ vô hiệu hóa. Các dòng nhật ký trỏ đến dòng này, và nếu từ chối thì nhà cung cấp sẽ thử lại mãi cho đến khi cách ly tác vụ
PATCH và PUTCó cả hai, vì Entra ID dùng patch còn Okta dùng replace. Cả hai quy về một phép so khác biệt thành viên và một lần đổi tên
PUTChỉ thay các trường của nhà cung cấp. Một lệnh replace đúng chuẩn hoàn toàn sẽ xóa phòng ban, vai trò trong tổ chức và trạng thái tạm khóa sau mỗi chu kỳ của Okta
Thành viênSo khác biệt. Đẩy lại mà không đổi gì thì không ghi gì. Thành viên không xác định hoặc thuộc nhóm lồng nhau được bỏ qua và đếm lại
Slug của nhómĐược suy ra. Đổi tên ở phía nhà cung cấp không làm slug thay đổi, vì URL của portal dựa trên nó
Xóa nhómXóa dây chuyền các thành viên, quyền vai trò được cấp và quy tắc phạm vi hiển thị. Sự kiện ghi rõ số lượng mỗi loại đã xóa
Đổi tênĐược chuyển sang tài khoản Keycloak, vì Keycloak liên kết lượt đăng nhập qua nhà cung cấp theo địa chỉ được trình
Vô hiệu hóaĐặt cờ tài khoản Keycloak theo việc chỗ ngồi còn cho phép truy cập hay không
NhómViệc cấp tài khoản chỉ chạm đến các nhóm do chính nó tạo, không nhóm nào khác

Đợt đồng bộ và nhật ký

Nhà cung cấp kiểu đẩy không bao giờ báo một chu kỳ bắt đầu, nên portal coi một đợt đồng bộ là một khung thời gian.

Quy tắcChi tiết
Khung thời gianThay đổi đầu tiên mở một đợt. Mọi thay đổi trong vòng mười phút kể từ thay đổi trước đó được tính vào đợt này. Thay đổi đến muộn hơn mở đợt tiếp theo
Lần đẩy bị từ chốiCó dòng thất bại riêng, mang trạng thái và lý do. Việc ghi sổ không bao giờ làm hỏng một lần ghi
Nhịp đẩyEntra ID đẩy cách nhau hai mươi đến bốn mươi phút. Connector vừa cấu hình một phút trước chưa có ai, và màn hình sẽ báo như vậy
Theo yêu cầuTính năng đẩy theo yêu cầu của nhà cung cấp gửi một người hoặc một nhóm cụ thể. Portal không thể yêu cầu đồng bộ
Nhật kýMọi lần ghi qua SCIM đều ghi một sự kiện quản trị với tác nhân hệ thống. Yêu cầu chưa xác thực không được ghi gì

Chế độ danh bạ

Chế độ danh bạ được chọn khi tạo tổ chức và mặc định là PORTAL, khi đó quản trị viên quản lý người dùng ngay trong portal. Ở chế độ IDP, nhà cung cấp là nguồn dữ liệu gốc: danh bạ đến qua SCIM và portal từ chối các thao tác ghi danh bạ thuộc về nhà cung cấp. Không màn hình nào đổi được chế độ về sau; đổi chế độ là một lần di chuyển dữ liệu, vì danh bạ PORTAL chứa người dùng, nhóm và phòng ban tạo thủ công mà nhà cung cấp chưa từng biết đến.

Chế độ IDP khóa những gì, và bên nào sở hữu trường nào, có ở Phòng ban › Chế độ thư mục.

Vì sao lại như vậy

Vì sao nhà cung cấp đẩy sang thay vì portal kéo về

Keycloak không có sẵn máy chủ SCIM. Kéo dữ liệu từ Keycloak Admin API cũng không thấy được người nghỉ việc: tài khoản kết nối qua nhà cung cấp vẫn ở trạng thái bật trong Keycloak sau khi Entra ID vô hiệu hóa nó. Vì vậy Entra ID đẩy SCIM thẳng đến portal.

Vì sao Delete chỉ vô hiệu hóa chứ không xóa

Các dòng nhật ký trỏ đến người đó, nên dòng phải được giữ lại. Còn nếu từ chối lệnh xóa, nhà cung cấp sẽ thử lại mãi cho đến khi cách ly tác vụ cấp tài khoản.

Vì sao PUT cố ý không đúng chuẩn hoàn toàn

Okta thay toàn bộ bản ghi ở mỗi chu kỳ. Một lệnh replace đúng chuẩn hoàn toàn sẽ xóa các trường do portal quản lý (phòng ban, vai trò trong tổ chức, tạm khóa) mỗi lần như vậy. Cả hai điểm lệch chuẩn đều có một bài kiểm thử sẽ thất bại nếu endpoint bị sửa cho đúng chuẩn.

Bên trong hệ thống

Route và mã định danh
  • Mười hai route SCIM bao phủ Users và Groups. Mỗi route nêu tên tổ chức trong đường dẫn, và một thông tin xác thực chỉ mở được tổ chức mà nó được tạo cho.
  • User id trong portal chính là Keycloak id. External id giữ object id của Entra ID.
  • Mỗi access token là một dòng trong cơ sở dữ liệu, nên thay thông tin xác thực sẽ thu hồi ngay mọi token dưới nó.
  • Token endpoint đọc cặp client từ thân biểu mẫu, từ header basic authorization, hoặc cả hai, vì Microsoft gửi cả hai. Nếu hai giá trị không khớp, yêu cầu bị từ chối.

Liên quan

Kết nối Entra ID Thiết lập nhà cung cấp và connector SCIM. Kết nối Okta Thiết lập cấp tài khoản với Okta. Phòng ban Chế độ danh bạ và ai sở hữu trường nào. Nhật ký kiểm tra Tìm các sự kiện quản trị do SCIM ghi.
AI Portal Docs
EN VI