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

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ả ACL trên các 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 đó, người dùng có thể được đại diện bằng tài khoản cục bộ hoặc 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 và mã nhận dạng, ngoài địa chỉ email của người dùng, để xác định từng tài khoản. Mã này đượ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 này giữa các hệ thống nhận dạng bằng cách:

Hãy 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 cải thiện hiệu quả lập chỉ mục bằng cách tách biệt hoạt động lập chỉ mục khỏi hoạt động ánh xạ danh tính. Việc tách biệt 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ề cách triển khai

Hình 1 cho thấy một ví dụ về việc triển khai mà một doanh nghiệp sử dụng cả kho lưu trữ trên máy và 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 để tham chiếu đến người dùng.

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

Kho lưu trữ 1 xác định người dùng bằng địa chỉ email được xác nhận bằng SAML. Vì kho lưu trữ 1 có thông tin về địa chỉ email chính của người dùng trong Google Workspace hoặc Cloud Directory, nên bạn không cần nguồn nhận dạng.

Kho lưu trữ 2 tích hợp trực tiếp với thư mục cục bộ và xác định người dùng theo thuộc tính sAMAccountName của họ. Vì kho lưu trữ 2 sử dụng thuộc tính sAMAccountName làm mã nhận dạng bên ngoài, nên bạn cần có 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 Ánh xạ danh tính người dùng trong Cloud Search.

Bạn phải tạo nguồn nhận dạng trước khi tạo trình kết nối nội dung vì bạn sẽ cần mã nguồn nhận dạng để tạo ACL và dữ liệu chỉ mục. Như đã đề cập trước đó, việc tạo nguồn nhận dạng cũng sẽ tạo một thuộc tính người dùng tuỳ chỉnh trong Thư mục trên đám mây. Sử dụng thuộc tính này để ghi lại mã nhận dạng bên ngoài cho mỗi người dùng trong kho lưu trữ. Thuộc tính này được đặt tên theo quy ước IDENTITY_SOURCE_ID_identity.

Bảng sau đây cho thấy hai nguồn nhận dạng, một nguồn để lưu trữ tên tài khoản SAM (sAMAccountName) dưới dạng mã nhận dạng bên ngoài và một nguồn để lưu trữ mã nhận dạng người dùng (uid) dưới dạng mã nhận dạng bên ngoài.

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

Tạo nguồn nhận dạng cho từng mã nhận dạng bên ngoài có thể dùng để tham chiếu đến một người dùng trong doanh nghiệp của bạn.

Bảng sau đâ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 (id1_identity và id2_identity) cũng như giá trị của các mã nhận dạng đó xuất hiện trong Thư mục trên đám mây:

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

Bạn có thể tham chiếu đến cùng một người dùng bằng 3 mã nhận dạng khác nhau (email Google, sAMAccountName và uid) khi tạo ACL để lập chỉ mục.

Ghi ACL của người dùng

Sử dụng phương thức getUserPrincpal() hoặc phương thức getGroupPrincipal() để tạo các nguyên tắc bằng mã nhận dạng bên ngoài được cung cấp.

Ví dụ sau đây minh hoạ cách truy xuất quyền đối với tệp. Các quyền này bao gồm tên của từng người dùng có quyền truy cập vào tệ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ã sau đây cho biết cách tạo các thực thể chính là chủ sở hữu bằng cách sử dụng mã nhận dạng bên ngoài (externalUserName) được lưu trữ trong các thuộc tính.

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

Cuối cùng, đoạn mã sau đây cho biết cách tạo các nguyên tắc là người đọc tệp.

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ó danh sách người đọc và chủ sở hữu, bạn có thể 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();

API REST cơ bản sử dụng mẫu identitysources/IDENTITY_SOURCE_ID/users/EXTERNAL_ID cho mã nhận dạng khi tạo các nguyên tắc. Tham khảo lại các bảng trước, nếu bạn tạo một ACL bằng id1_identity (SAMAccountName) của Ann, thì mã nhận dạng sẽ phân giải thành:

identitysources/id1_identity/users/example/ann

Toàn bộ mã nhận dạng này được gọi là mã nhận dạng trung gian của người dùng vì mã này tạo cầu nối giữa mã nhận dạng bên ngoài và mã nhận dạng của Google được lưu trữ bằng Thư mục trên đám mây.

Để biết thêm thông tin về cách lập mô hình ACL dùng cho 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 được dùng trong ACL. Bạn có thể sử dụng tính nă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 là nhóm cục bộ của một kho lưu trữ.

Sử dụng Cloud Identity Groups API để tạo nhóm và quản lý các thành viên. Để liên kết nhóm với một nguồn nhận dạng, hãy sử dụng tên tài nguyên nguồn nhận dạng làm không gian tên nhóm.

Đoạn mã sau đây cho biết cách tạo một nhóm bằng Cloud Identity Groups API:

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 ACL nhóm

Để tạo ACL nhóm, hãy sử dụng phương thức getGroupPrincipal() để tạo một nguyên tắc nhóm bằng mã nhận dạng bên ngoài được cung cấp. Sau đó, hãy tạo ACL bằng lớp Acl.Builder như sau:

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

Mặc dù bạn có thể sử dụng mã nhận dạng bên ngoài, không phải của Google để tạo ACL và mục chỉ mục, nhưng người dùng sẽ không 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ã nhận dạng của Google trong Cloud Directory. Có 3 cách để đảm bảo rằng Thư mục trên đám mây biết cả mã nhận dạng Google và mã nhận dạng bên ngoài của người dùng:

Trình kết nối danh tính là các chương trình dùng để liên kết mã nhận dạng bên ngoài từ danh tính của doanh nghiệp (người dùng và nhóm) với danh tính nội bộ của Google mà Google Cloud Search sử dụng. Nếu phải tạo nguồn nhận dạng, bạn phải tạo 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. Trình kết nối danh tính này liên kết thông tin người dùng và nhóm từ Active Directory của Microsoft với Cloud Directory cùng với các thuộc tính người dùng có thể đại diện cho danh tính của họ trong các hệ thống khác.

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

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

Ánh xạ lại danh tính

Sau khi liên kết lại danh tính của một mục với một danh tính khác, bạn phải lập chỉ mục lại các mục để danh tính mới có hiệu lực. Ví dụ:

  • nếu bạn cố gắng xoá mối liên kết khỏi một người dùng hoặc liên kết lại mối liên kết đó với một người dùng khác, thì mối liên kết ban đầu vẫn được giữ nguyê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 có trong ACL của mục, sau đó 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 vào mục đó cho đến khi mục được lập chỉ mục lại.