Synchronizowanie różnych systemów tożsamości

Kontrola dostępu w Google Cloud Search opiera się na koncie Google użytkownika. Podczas indeksowania treści wszystkie listy ACL dotyczące elementów muszą być rozwiązywane do prawidłowych identyfikatorów użytkowników lub grup Google (adresów e-mail).

W wielu przypadkach repozytorium nie ma bezpośredniej wiedzy o kontach Google. Zamiast tego użytkownicy mogą być reprezentowani przez konta lokalne lub używać logowania federowanego z dostawcą tożsamości i identyfikatorem innym niż adres e-mail użytkownika, aby zidentyfikować każde konto. Ten identyfikator nazywa się identyfikatorem zewnętrznym.

Źródła tożsamości utworzone za pomocą konsoli administracyjnej pomagają wypełnić tę lukę między systemami tożsamości, ponieważ:

• Zdefiniuj niestandardowe pole użytkownika na potrzeby przechowywania zewnętrznych identyfikatorów. To pole służy do mapowania identyfikatorów zewnętrznych na konto Google.
• Zdefiniuj przestrzeń nazw dla grup zabezpieczeń zarządzanych przez repozytorium lub dostawcę tożsamości.

Używaj źródeł tożsamości, gdy:

• Repozytorium nie ma informacji o głównym adresie e-mail użytkownika w Google Workspace ani w Google Cloud Directory.
• Repozytorium definiuje grupy kontroli dostępu, które nie odpowiadają grupom opartym na adresie e-mail w Google Workspace.

Źródła tożsamości zwiększają wydajność indeksowania przez odłączenie indeksowania od mapowania tożsamości. Dzięki temu możesz odłożyć sprawdzenie użytkownika na później, gdy tworzysz listy kontroli dostępu i indeksujesz elementy.

Przykładowe wdrożenie

Rysunek 1 przedstawia przykładową implementację, w której firma korzysta zarówno z repozytoriów lokalnych, jak i z repozytoriów w chmurze. Każde repozytorium używa innego typu identyfikatora zewnętrznego do odwoływania się do użytkowników.

Repozytorium 1 identyfikuje użytkownika za pomocą adresu e-mail potwierdzonego za pomocą protokołu SAML. Repozytorium 1 zna podstawowy adres e-mail użytkownika w Google Workspace lub Cloud Directory, więc źródło tożsamości nie jest potrzebne.

Repozytorium 2 integruje się bezpośrednio z katalogiem lokalnym i identyfikuje użytkownika za pomocą atrybutu sAMAccountName. Repozytorium 2 używa atrybutu sAMAccountName jako identyfikatora zewnętrznego, więc potrzebne jest źródło tożsamości.

Tworzenie źródła tożsamości

Jeśli potrzebujesz źródła tożsamości, zapoznaj się z artykułem Mapowanie tożsamości użytkowników w Cloud Search.

Zanim utworzysz łącznik treści, musisz utworzyć źródło tożsamości, ponieważ do tworzenia list ACL i indeksowania danych potrzebny jest identyfikator źródła tożsamości. Jak już wspomnieliśmy, utworzenie źródła tożsamości powoduje też utworzenie własności użytkownika niestandardowej w Cloud Directory. Użyj tej właściwości, aby zapisać zewnętrzny identyfikator każdego użytkownika w repozytorium. Nazwa właściwości jest tworzona zgodnie z konwencją IDENTITY_SOURCE_ID_identity.

Poniższa tabela zawiera 2 źródła tożsamości: jedno z nazwami kont SAM (sAMAccountName) jako identyfikatorami zewnętrznymi i drugie z identyfikatorami użytkowników (uid) jako identyfikatorami zewnętrznymi.

Utwórz źródło tożsamości dla każdego możliwego identyfikatora zewnętrznego, który jest używany do odwoływania się do użytkownika w Twojej firmie.

W tabeli poniżej pokazano, jak użytkownik z kontem Google i 2 identyfikatorami zewnętrznymi (id1_identity i id2_identity) oraz ich wartościami wygląda w katalogu Cloud Directory:

Podczas tworzenia list ACL na potrzeby indeksowania możesz odwoływać się do tego samego użytkownika, używając 3 różnych identyfikatorów (adresu e-mail w Google, nazwy konta SAM i identyfikatora uid).

Zapisz listy ACL użytkownika

Aby utworzyć podmioty za pomocą podanego identyfikatora zewnętrznego, użyj metody getUserPrincpal() lub getGroupPrincipal().

Ten przykład pokazuje, jak pobrać uprawnienia do pliku. Te uprawnienia obejmują nazwę każdego użytkownika, który ma dostęp do pliku.

/**
 * 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();
  // ...
}

Ten fragment kodu pokazuje, jak tworzyć podmioty będące właścicielami za pomocą identyfikatora zewnętrznego (externalUserName) przechowywanego w atrybutach.

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

Na koniec ten fragment kodu pokazuje, jak utworzyć podmioty, które są czytelnikami pliku.

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

Gdy masz już listę czytelników i właścicieli, możesz utworzyć listę ACL:

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

Interfejs API REST używa w przypadku identyfikatorów wzorców identitysources/IDENTITY_SOURCE_ID/users/EXTERNAL_IDdo tworzenia podmiotów. Wróćmy do poprzednich tabel. Jeśli utworzysz tabelę ACL z użytkownikiem id1_identity (SAMAccountName) Ann, identyfikator będzie miał wartość:

identitysources/id1_identity/users/example/ann

Ten identyfikator jest nazywany pośrednim identyfikatorem użytkownika, ponieważ stanowi łącznik między zewnętrznym identyfikatorem a identyfikatorami Google przechowywanymi w katalogu Cloud Directory.

Więcej informacji o modelowaniu uprawnień ACL używanych w repozytorium znajdziesz w artykule Uprawnienia ACL.

Grupy map

Źródła tożsamości służą też jako przestrzeń nazw dla grup używanych w regułach dostępu. Za pomocą tej funkcji przestrzeni nazw możesz tworzyć i mapować grupy używane tylko do celów zabezpieczeń lub lokalne w repozytorium.

Utwórz grupę i zarządzaj członkostwem w niej za pomocą interfejsu Cloud Identity Groups API. Aby powiązać grupę ze źródłem tożsamości, użyj nazwy zasobu źródła tożsamości jako przestrzeni nazw grupy.

Ten fragment kodu pokazuje, jak utworzyć grupę za pomocą interfejsu Cloud Identity Groups API:

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

Tworzenie listy ACL grupy

Aby utworzyć grupę ACL, użyj metody getGroupPrincipal(), aby utworzyć obiekt głównego grupy przy użyciu podanego identyfikatora zewnętrznego. Następnie utwórz ACL za pomocą klasy Acl.Builder w ten sposób:

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

Oprogramowanie sprzęgające tożsamości

Do tworzenia list ACL i indeksowania elementów można używać zewnętrznych identyfikatorów spoza Google, ale użytkownicy nie będą widzieć elementów w wynikach wyszukiwania, dopóki ich zewnętrzne identyfikatory nie zostaną przekształcone w identyfikatory Google w katalogu Cloud. Aby mieć pewność, że katalog usługi Cloud Directory zna zarówno identyfikator Google, jak i identyfikatory zewnętrzne użytkownika, możesz skorzystać z 3 sposobów:

• Ręcznie aktualizuj każdy profil użytkownika w konsoli administracyjnej. Ten proces jest zalecany tylko w przypadku testowania i tworzenia prototypów z użyciem kilku profili użytkowników.
• Przypisz identyfikatory zewnętrzne do identyfikatorów Google za pomocą interfejsu Directory API. Ten proces jest zalecany osobom, które nie mogą używać pakietu SDK Identity Connector.
• Utwórz oprogramowanie sprzęgające tożsamości za pomocą pakietu SDK oprogramowania sprzęgającego tożsamości. Ten pakiet SDK upraszcza korzystanie z interfejsu Directory API do mapowania identyfikatorów.

Łączniki tożsamości to programy służące do mapowania zewnętrznych identyfikatorów tożsamości (użytkowników i grup) na wewnętrzne tożsamości Google używane przez Google Cloud Search. Jeśli musisz utworzyć źródło tożsamości, musisz też utworzyć łącznik tożsamości.

Google Cloud Directory Sync (GCDS) to przykład łącznika tożsamości. Ten łącznik tożsamości mapuje informacje o użytkownikach i grupach z Microsoft Active Directory na Cloud Directory wraz z atrybutami użytkowników, które mogą reprezentować ich tożsamość w innych systemach.

Synchronizowanie tożsamości za pomocą interfejsu API REST

Aby zsynchronizować tożsamości za pomocą interfejsu API REST, użyj metody update.

Ponownie mapowanie tożsamości

Po przypisaniu tożsamości elementu do innej tożsamości musisz ponownie zindeksować elementy, aby nowa tożsamość zaczęła obowiązywać. Na przykład

• Jeśli spróbujesz usunąć mapowanie od użytkownika lub zmienić jego mapowanie na innego użytkownika, oryginalne mapowanie będzie nadal zachowane, dopóki nie przeprowadzisz ponownego indeksowania.
• Jeśli usuniesz zmapowaną grupę obecną w zasadach dostępu do elementu, a następnie utworzysz nową grupę z tym samym identyfikatorem groupKey, nowa grupa nie zapewni dostępu do elementu, dopóki nie zostanie on ponownie zindeksowany.