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

Quyền kiểm soát 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ả ACL của mục 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ó kiến thức 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 danh tính. Thông tin 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 Danh mục Google Cloud.
  • 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 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 ACL và lập chỉ mục các mục.

Ví dụ về việc 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à trên đám mây. Mỗi loại sử dụng một loại mã nhận dạng bên ngoài riêng.

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ề việc triển khai doanh nghiệp với các loại danh tính khác nhau.

Kho lưu trữ 1 xác định người dùng bằng địa chỉ email thông qua SAML. Vì biết địa chỉ email chính trong Google Workspace hoặc Cloud Directory, nên ứng dụng 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 cơ sở và xác định người dùng bằng sAMAccountName. Vì sử dụng thuộc tính này làm mã nhận dạng bên ngoài, nên thuộc tính này yêu cầu một nguồn nhận dạng.

Tạo một nguồn nhận dạng

Nếu bạn cần một nguồn nhận dạng, hãy xem phần Ánh xạ 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 truy cập và lập chỉ mục dữ liệu. Việc tạo một nguồn nhận dạng cũng sẽ 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 cho tên tài khoản SAM và một 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 dùng trong doanh nghiệp của bạn.

Bảng này cho biết cách một người dùng có Tài khoản Google và hai 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 cách sử dụng bất kỳ mã nhận dạng nào trong số này khi tạo ACL để lập chỉ mục.

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

Sử dụng getUserPrincipal() hoặc getGroupPrincipal() để tạo các đối tượng chính 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ể chính cho chủ sở hữu bằng cách sử dụ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 ra các đối tượng chính 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 bạn có người đọc và chủ sở hữu, hãy tạo ACL:

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();

REST API 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ề việc mô hình hoá ACL kho lưu trữ, hãy xem phần ACL.

Nhóm bản đồ

Nguồn nhận dạng cũng đóng vai trò là không gian tên cho các nhóm ACL. Sử dụng lệnh 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 một ACL nhóm

Sử dụng getGroupPrincipal() để tạo một nhóm chính có mã nhận dạng bên ngoài, sau đó tạo ACL:

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ục 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 các mã nhận dạng bên ngoài của danh tính doanh nghiệp với danh tính nội bộ của Google. Nếu tạo một nguồn nhận dạng, bạn cũng phải tạo một trình kết nối nhận dạng.

Google Cloud Directory Sync (GCDS) là một ví dụ về trình kết nối danh tính. Thao tác này ánh xạ thông tin người dùng và nhóm từ Active Directory sang Cloud Directory.

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

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 ánh xạ lại một danh tính, bạn phải lập chỉ mục lại các mục để thay đổi có hiệu lực.

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