Ta strona została przetłumaczona przez Cloud Translation API.

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

Kontrola dostępu w Google Cloud Search zależy od konta Google użytkownika. Podczas indeksowania treści wszystkie listy kontroli dostępu elementów muszą być dopasowane do prawidłowych identyfikatorów użytkowników lub grup (adresów e-mail) Google.

W wielu przypadkach repozytorium nie ma bezpośredniej wiedzy o kontach Google. Zamiast tego użytkownicy mogą być reprezentowani przez konta lokalne lub do identyfikowania poszczególnych kont używać logowania sfederowanego z użyciem dostawcy tożsamości i identyfikatora innego niż adres e-mail użytkownika. Jest to tzw. identyfikator zewnętrzny.

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

Utworzenie niestandardowego pola użytkownika do przechowywania zewnętrznych identyfikatorów. To pole służy do przypisywania zewnętrznych identyfikatorów do konta Google.
Zdefiniuj przestrzeń nazw dla grup zabezpieczeń zarządzaną przez repozytorium lub dostawcę tożsamości.

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

Repozytorium nie zna podstawowego adresu e-mail użytkownika w Google Workspace ani w Google Cloud Directory.
Repozytorium określa grupy kontroli dostępu, które nie odpowiadają grupom opartym na adresach e-mail w Google Workspace.

Źródła tożsamości poprawiają wydajność indeksowania, ponieważ oddzielają indeksowanie od mapowania tożsamości. Takie rozłączenie umożliwia opóźnienie wyszukiwania użytkownika podczas tworzenia list kontroli dostępu i elementów indeksowania.

Przykładowe wdrożenie

Rysunek 1 przedstawia przykładowe wdrożenie, w którym przedsiębiorstwo używa zarówno repozytoriów lokalnych, jak i w chmurze. Każde repozytorium używa innego typu identyfikatora zewnętrznego do odwołań do użytkowników.

Repozytorium 1 identyfikuje użytkownika na podstawie adresu e-mail zweryfikowanego za pomocą SAML. Repozytorium 1 wie o podstawowym adresie 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.

Przed utworzeniem oprogramowania sprzęgającego treści musisz utworzyć źródło tożsamości, ponieważ identyfikator źródła tożsamości będzie potrzebny do tworzenia list kontroli dostępu i danych indeksu. Jak już wspomnieliśmy, utworzenie źródła tożsamości powoduje też utworzenie niestandardowej właściwości użytkownika w Cloud Directory. Dzięki tej właściwości możesz rejestrować zewnętrzny identyfikator każdego użytkownika w repozytorium. Nazwa właściwości jest zgodna z konwencją IDENTITY_SOURCE_ID_identity.

W tabeli poniżej znajdziesz 2 źródła tożsamości: jedno do przechowywania nazw kont SAM (sAMAccountName) jako identyfikatorów zewnętrznych, a drugie do przechowywania identyfikatorów użytkowników (uid) jako identyfikatorów zewnętrznych.

Źródło tożsamości	właściwość użytkownika	identyfikator zewnętrzny
id1	id1_identity	sAMAccountName
id2	id2_identity	uid

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

W tabeli poniżej pokazujemy, jak użytkownik mający konto Google i 2 identyfikatory zewnętrzne (id1_identity i id2_identity) wyświetlają się w Cloud Directory:

użytkownik	email	id1_identity	id2_identity
Anna	ann@example.com	przykład\ann	1001

Możesz odwoływać się do tego samego użytkownika za pomocą 3 różnych identyfikatorów (adres e-mail Google, sAMAccountName i uid) podczas tworzenia list kontroli dostępu na potrzeby indeksowania.

Zapisywanie list kontroli dostępu użytkowników

Użyj metody getUserPrincpal() lub getGroupPrincipal(), aby utworzyć podmioty zabezpieczeń z użyciem podanego identyfikatora zewnętrznego.

Przykład poniżej pokazuje, jak pobrać uprawnienia dotyczące pliku. Uprawnienia te obejmują nazwę każdego użytkownika, który ma dostęp do pliku.

FilePermissionSample.java

Wyświetl w GitHubie

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

Poniższy fragment kodu pokazuje, jak utworzyć podmioty zabezpieczeń, które są właścicielami, za pomocą identyfikatora zewnętrznego (externalUserName) zapisanego w atrybutach.

FilePermissionSample.java

Wyświetl w GitHubie

// 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 fragment kodu poniżej pokazuje, jak tworzyć podmioty zabezpieczeń, które będą czytać plik.

FilePermissionSample.java

Wyświetl w GitHubie

// 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ę kontroli dostępu:

FilePermissionSample.java

Wyświetl w GitHubie

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

Podczas tworzenia podmiotów zabezpieczeń podstawowy interfejs API REST używa wzorca identitysources/IDENTITY_SOURCE_ID/users/EXTERNAL_ID dla identyfikatora. Jeśli utworzysz listę kontroli dostępu (ACL) z użyciem parametru id1_identity Anny (SAMAccountName), identyfikator będzie wskazywał poprzednie tabele:

identitysources/id1_identity/users/example/ann

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

Więcej informacji na temat modelowania list kontroli dostępu używanych na potrzeby repozytorium znajdziesz w artykule Listy kontroli dostępu.

Grupy map

Źródła tożsamości służą też jako przestrzeń nazw dla grup używanych na listach kontroli dostępu. Tej funkcji przestrzeni nazw możesz użyć do tworzenia i mapowania grup, które są używane tylko do celów związanych z bezpieczeństwem lub są dostępne lokalnie w repozytorium.

Aby utworzyć grupę i zarządzać członkostwem, użyj 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ę przy użyciu interfejsu Cloud Identity Groups API:

CreateGroupCommand.java

Wyświetl w GitHubie

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

Utwórz listę ACL grupy

Aby utworzyć listę kontroli dostępu grupy, użyj metody getGroupPrincipal() w celu utworzenia podmiotu zabezpieczeń grupy przy użyciu podanego identyfikatora zewnętrznego. Następnie za pomocą klasy Acl.Builder utwórz listę kontroli dostępu w następujący sposób:

FilePermissionSample.java

Wyświetl w GitHubie

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

Mimo że do tworzenia list kontroli dostępu i elementów indeksowania możesz używać zewnętrznych identyfikatorów spoza Google, użytkownicy nie widzą elementów w wynikach wyszukiwania, dopóki ich zewnętrzne identyfikatory nie zostaną dopasowane do identyfikatora Google w Cloud Directory. Istnieją 3 sposoby, aby sprawdzić, czy Cloud Directory zna zarówno identyfikator Google, jak i identyfikatory zewnętrzne użytkownika:

Ręcznie zaktualizuj każdy profil każdego użytkownika w konsoli administracyjnej. Ten proces jest zalecany tylko w przypadku testowania i prototypowania profili użytkowników z wykorzystaniem kilku profili użytkowników.
Zmapuj identyfikatory zewnętrzne na identyfikatory Google za pomocą interfejsu Directory API. Ten proces jest zalecany dla osób, które nie mogą korzystać z pakietu SDK Identity Connector.
Utwórz oprogramowanie sprzęgające tożsamości za pomocą pakietu SDK Identity Connector. Ten pakiet SDK upraszcza korzystanie z interfejsu Directory API do mapowania identyfikatorów.

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

Przykładem oprogramowania sprzęgającego tożsamości jest Google Cloud Directory Sync (GCDS). To oprogramowanie sprzęgające tożsamości mapuje informacje o użytkownikach i grupach z usługi Active Directory firmy Microsoft do Cloud Directory wraz z atrybutami użytkowników, które mogą reprezentować ich tożsamość w innych systemach.

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

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

Mapowanie tożsamości

Po zmapowaniu tożsamości elementu na inną tożsamość musisz ponownie zindeksować elementy, aby uwzględnić nową tożsamość. Przykład:

jeśli spróbujesz usunąć mapowanie z użytkownika lub ponownie zmapować je na innego użytkownika, pierwotne mapowanie pozostanie zachowywane do momentu ponownego zindeksowania.
Jeśli usuniesz zmapowaną grupę, która znajduje się na liście kontroli dostępu elementów, a następnie utworzysz nową grupę z takim samym atrybutem groupKey, nowa grupa nie udostępni elementu, dopóki nie zostanie ponownie zindeksowany.