Đồng bộ hóa các hệ thống nhận dạng khác nhau

Cơ chế kiểm soát quyền truy cập trong Google Cloud Search dựa trên Tài khoản Google của người dùng. Khi lập chỉ mục nội dung, tất cả danh sách kiểm soát quyền truy cập (ACL) của mặt hàng phải phân giải thành mã nhận dạng người dùng hoặc nhóm hợp lệ của Google (địa chỉ email).

Trong nhiều trường hợp, kho lưu trữ không có thông tin trực tiếp về Tài khoản Google. Thay vào đó, tài khoản cục bộ đại diện cho người dùng hoặc người dùng sử dụng tính năng đăng nhập liên kết với một nhà cung cấp dịch vụ danh tính. Giá trị nhận dạng này, ngoài địa chỉ email, được gọi là mã nhận dạng bên ngoài.

Được tạo bằng Bảng điều khiển dành cho quản trị viên, nguồn nhận dạng giúp thu hẹp khoảng cách giữa các hệ thống nhận dạng bằng cách:

Sử dụng nguồn nhận dạng khi:

  • Kho lưu trữ không biết địa chỉ email chính của người dùng trong Google Workspace hoặc Google Cloud Directory.
  • Kho lưu trữ xác định các nhóm kiểm soát quyền truy cập không tương ứng với các nhóm dựa trên email trong Google Workspace.

Nguồn nhận dạng giúp cải thiện hiệu quả bằng cách tách việc lập chỉ mục khỏi việc liên kết danh tính. Điều này cho phép bạn trì hoãn việc tra cứu người dùng khi tạo danh sách kiểm soát quyền truy cập và lập chỉ mục các mặt hàng.

Ví dụ về cách triển khai

Hình 1 cho thấy một doanh nghiệp sử dụng cả kho lưu trữ tại chỗ và kho lưu trữ trên đám mây. Mỗi kho lưu trữ sử dụng một loại mã nhận dạng bên ngoài khác nhau.

Ví dụ về việc triển khai doanh nghiệp với nhiều loại danh tính
Hình 1. Ví dụ về cách triển khai doanh nghiệp với nhiều loại danh tính.

Kho lưu trữ 1 xác định người dùng theo địa chỉ email bằng SAML. Vì biết địa chỉ email chính trong Google Workspace hoặc Cloud Directory, nên kho lưu trữ này không cần nguồn nhận dạng.

Kho lưu trữ 2 tích hợp với một thư mục tại chỗ và xác định người dùng theo sAMAccountName. Vì sử dụng thuộc tính này làm mã nhận dạng bên ngoài, nên kho lưu trữ này yêu cầu một nguồn nhận dạng.

Tạo nguồn nhận dạng

Nếu bạn cần một nguồn nhận dạng, hãy xem bài viết Liên kết danh tính người dùng trong Cloud Search.

Tạo nguồn nhận dạng trước khi tạo trình kết nối nội dung; bạn cần có mã nhận dạng của nguồn nhận dạng để tạo danh sách kiểm soát quyền truy cập và lập chỉ mục dữ liệu. Việc tạo nguồn nhận dạng cũng tạo ra một thuộc tính người dùng tuỳ chỉnh trong Cloud Directory để lưu trữ mã nhận dạng bên ngoài. Tên thuộc tính sử dụng quy ước IDENTITY_SOURCE_ID_identity.

Bảng này cho thấy 2 nguồn nhận dạng: một nguồn cho tên tài khoản SAM và một nguồn cho mã nhận dạng người dùng (uid).

Nguồn nhận dạng Thuộc tính người dùng ID bên ngoài
id1 id1_identity sAMAccountName
id2 id2_identity uid

Tạo một nguồn nhận dạng cho từng loại mã nhận dạng bên ngoài được sử dụng trong doanh nghiệp của bạn.

Bảng này cho thấy cách một người dùng có Tài khoản Google và 2 mã nhận dạng bên ngoài xuất hiện trong Cloud Directory:

Người dùng Email id1_identity id2_identity
Ann ann@example.com example\ann 1001

Bạn có thể tham chiếu cùng một người dùng bằng bất kỳ mã nhận dạng nào trong số này khi tạo danh sách kiểm soát quyền truy cập để lập chỉ mục.

Viết danh sách kiểm soát quyền truy cập của người dùng

Sử dụng getUserPrincipal() hoặc getGroupPrincipal() để tạo các thực thể bằng mã nhận dạng bên ngoài.

Ví dụ này truy xuất các quyền đối với tệp, bao gồm cả những người dùng có quyền truy cập:

FilePermissionSample.java
/**
 * Sample for mapping permissions from a source repository to Cloud Search
 * ACLs. In this example, POSIX file permissions are used a the source
 * permissions.
 *
 * @return Acl
 * @throws IOException if unable to read file permissions
 */
static Acl mapPosixFilePermissionToCloudSearchAcl(Path pathToFile) throws IOException {
  // Id of the identity source for external user/group IDs. Shown here,
  // but may be omitted in the SDK as it is automatically applied
  // based on the `api.identitySourceId` configuration parameter.
  String identitySourceId = "abcdef12345";

  // Retrieve the file system permissions for the item being indexed.
  PosixFileAttributeView attributeView = Files.getFileAttributeView(
      pathToFile,
      PosixFileAttributeView.class,
      LinkOption.NOFOLLOW_LINKS);

  if (attributeView == null) {
    // Can't read, return empty ACl
    return new Acl.Builder().build();
  }

  PosixFileAttributes attrs = attributeView.readAttributes();
  // ...
}

Đoạn mã này tạo các thực thể cho chủ sở hữu bằng thuộc tính externalUserName:

FilePermissionSample.java
// Owner, for search quality.
// Note that for principals the name is not the primary
// email address in Cloud Directory, but the local ID defined
// by the OS. Users and groups must be referred to by their
// external ID and mapped via an identity source.
List<Principal> owners = Collections.singletonList(
    Acl.getUserPrincipal(attrs.owner().getName(), identitySourceId)
);

Đoạn mã này tạo các thực thể cho người đọc:

FilePermissionSample.java
// List of users to grant access to
List<Principal> readers = new ArrayList<>();

// Add owner, group, others to readers list if permissions
// exist. For this example, other is mapped to everyone
// in the organization.
Set<PosixFilePermission> permissions = attrs.permissions();
if (permissions.contains(PosixFilePermission.OWNER_READ)) {
  readers.add(Acl.getUserPrincipal(attrs.owner().getName(), identitySourceId));
}
if (permissions.contains(PosixFilePermission.GROUP_READ)) {
  String externalGroupName = attrs.group().getName();
  Principal group = Acl.getGroupPrincipal(externalGroupName, identitySourceId);
  readers.add(group);
}
if (permissions.contains(PosixFilePermission.OTHERS_READ)) {
  Principal everyone = Acl.getCustomerPrincipal();
  readers.add(everyone);
}

Sau khi có người đọc và chủ sở hữu, hãy tạo danh sách kiểm soát quyền truy cập:

FilePermissionSample.java
// Build the Cloud Search ACL. Note that inheritance of permissions
// from parents is omitted. See `setInheritFrom()` and `setInheritanceType()`
// methods on the builder if required by your implementation.
Acl acl = new Acl.Builder()
    .setReaders(readers)
    .setOwners(owners)
    .build();

API REST sử dụng mẫu identitysources/IDENTITY_SOURCE_ID/users/EXTERNAL_ID. id1_identity của Ann phân giải thành identitysources/id1_identity/users/example/ann. Đây là mã nhận dạng trung gian của người dùng.

Để biết thêm thông tin về cách mô hình hoá danh sách kiểm soát quyền truy cập của kho lưu trữ, hãy xem bài viết Danh sách kiểm soát quyền truy cập.

Liên kết các nhóm

Nguồn nhận dạng cũng đóng vai trò là không gian tên cho các nhóm danh sách kiểm soát quyền truy cập. Sử dụng không gian tên này để tạo và liên kết các nhóm chỉ dùng cho mục đích bảo mật hoặc cục bộ với một kho lưu trữ.

Sử dụng Cloud Identity Groups API để tạo nhóm và quản lý tư cách thành viên. Liên kết nhóm với một nguồn nhận dạng bằng cách sử dụng tên nguồn nhận dạng làm không gian tên.

Đoạn mã này tạo một nhóm:

CreateGroupCommand.java
String namespace = "identitysources/" + idSource;
Group group = new Group()
    .setGroupKey(new EntityKey().setNamespace(namespace).setId(groupId))
    .setDescription("Demo group")
    .setDisplayName(groupName)
    .setLabels(Collections.singletonMap("system/groups/external", ""))
    .setParent(namespace);
try {
  CloudIdentity service = Utils.buildCloudIdentityService();
  Operation createOperation = service.groups().create(group).execute();

  if (createOperation.getDone()) {
    // Note: The response contains the data for a Group object, but as
    // individual fields. To convert to a Group instance, either populate
    // the fields individually or serialize & deserialize to/from JSON.
    //
    // Example:
    // String json = service.getJsonFactory().toString(response);
    // Group createdGroup =  service.getObjectParser()
    //     .parseAndClose(new StringReader(json), Group.class);
    System.out.printf("Group: %s\n",
        createOperation.getResponse().toString());
  } else {
    // Handle case where operation not yet complete, poll for
    // completion. API is currently synchronous and all operations return
    // as completed.
    // ...
  }
} catch (Exception e) {
  System.err.printf("Unable to create group: %s", e.getMessage());
  e.printStackTrace(System.err);
}

Tạo danh sách kiểm soát quyền truy cập của nhóm

Sử dụng getGroupPrincipal() để tạo một thực thể nhóm có mã nhận dạng bên ngoài, sau đó tạo danh sách kiểm soát quyền truy cập:

FilePermissionSample.java
if (permissions.contains(PosixFilePermission.GROUP_READ)) {
  String externalGroupName = attrs.group().getName();
  Principal group = Acl.getGroupPrincipal(externalGroupName, identitySourceId);
  readers.add(group);
}

Trình kết nối danh tính

Người dùng không thể thấy các mặt hàng trong kết quả tìm kiếm cho đến khi mã nhận dạng bên ngoài của họ phân giải thành một mã nhận dạng Google trong Cloud Directory. Bạn có thể đảm bảo điều này theo 3 cách:

Trình kết nối danh tính liên kết mã nhận dạng bên ngoài từ danh tính doanh nghiệp với danh tính nội bộ của Google. Nếu tạo nguồn nhận dạng, bạn cũng phải tạo trình kết nối danh tính.

Google Cloud Directory Sync (GCDS) là một ví dụ về trình kết nối danh tính. Trình kết nối này liên kết thông tin người dùng và nhóm từ Active Directory với Cloud Directory.

Đồng bộ hoá danh tính bằng API REST

Sử dụng phương thức update để đồng bộ hoá danh tính.

Liên kết lại danh tính

Sau khi liên kết lại danh tính, bạn phải lập chỉ mục lại các mặt hàng để thay đổi có hiệu lực.

  • Nếu bạn xoá hoặc thay đổi mối liên kết người dùng, thì mối liên kết ban đầu vẫn còn cho đến khi bạn lập chỉ mục lại.
  • Nếu bạn xoá một nhóm đã liên kết và tạo một nhóm mới có cùng groupKey, thì nhóm đó sẽ không cấp quyền truy cập cho đến khi bạn lập chỉ mục lại.