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 jest oparta na koncie Google użytkownika. Podczas indeksowania treści wszystkie listy kontroli dostępu dla elementów muszą być przypisane do prawidłowego użytkownika Google lub identyfikatorów grup (adresów e-mail).

W wielu przypadkach repozytorium nie dysponuje bezpośrednią wiedzą o Google, kont. Zamiast tego użytkownicy mogą być reprezentowani przez konta lokalne lub używać atrybutu logowanie sfederowane z użyciem dostawcy tożsamości i identyfikatora, inne niż adres e-mail użytkownika, aby zidentyfikować każde z nich. Jest to tzw. identyfikator identyfikator zewnętrzny.

Utworzone za pomocą konsoli administracyjnej źródła tożsamości pomagają wypełnić lukę systemów tożsamości:

Zdefiniuj niestandardowe pole użytkownika do przechowywania identyfikatorów zewnętrznych. To pole służy do przekazywania identyfikatorów zewnętrznych do identyfikatora Google. koncie.
Zdefiniuj przestrzeń nazw dla grup zabezpieczeń. zarządzane przez repozytorium lub dostawcą tożsamości.

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

Repozytorium nie ma informacji o podstawowym adresie e-mail użytkownik w Google Workspace lub Google Cloud Directory.
Repozytorium definiuje grupy na potrzeby kontroli dostępu, które nie odpowiadają do grup opartych na e-mailach w Google Workspace.

Źródła tożsamości poprawiają efektywność indeksowania dzięki rozłączeniu indeksowania z mapowania tożsamości. To odłączenie pozwala opóźnić wyszukiwanie użytkownika podczas tworzenia list kontroli dostępu i indeksowania elementów.

Przykładowe wdrożenie

Ilustracja 1 przedstawia przykładowe wdrożenie, w którym zarówno lokalnie, jak i w chmurze Repozytoria są używane przez firmę. Każde repozytorium używa innego typu zewnętrznego identyfikatora, aby odwołać się do użytkowników.

Repozytorium 1 identyfikuje użytkownika na podstawie adresu e-mail zarejestrowanego za pomocą SAML. Ponieważ repozytorium 1 zna podstawowy adres e-mail użytkownika w Google Workspace lub Cloud Directory, ź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. Ponieważ repozytorium 2 Używa atrybutu sAMAccountName jako identyfikatora zewnętrznego, a źródłem tożsamości jest niezbędną.

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

Jeśli potrzebujesz źródła tożsamości, przeczytaj artykuł 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ż potrzebujesz identyfikatora źródła tożsamości do tworzenia list kontroli dostępu i danych indeksowania. Jak wspomniano wcześniej utworzenie źródła tożsamości powoduje też utworzenie niestandardowa właściwość użytkownika w Cloud Directory. Użyj tej usługi, aby zarejestrować identyfikator zewnętrzny dla każdego użytkownika w repozytorium. Nazwa właściwości pojawia się za pomocą atrybutu IDENTITY_SOURCE_ID_identity.

Tabela poniżej zawiera 2 źródła tożsamości, w tym jedno z nazwami kont SAM (sAMAccountName) jako identyfikatory zewnętrzne, a drugi 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 jest używany do odnosi się do użytkownika w Twojej firmie.

W tabeli poniżej pokazujemy, jak użytkownik z kontem Google i 2 identyfikatorami zewnętrznymi (id1_identity oraz id2_identity) i ich wartości pojawiają się w Cloud Directory:

użytkownik	e-mail	id1_identity	id2_identity
Anna	ann@example.com	przykład\anna	1001

Możesz odwołać się do tego samego użytkownika, używając 3 różnych identyfikatorów: (Adres e-mail Google, sAMAccountName i Uid) podczas tworzenia list kontroli dostępu do indeksowania.

Zapisywanie list kontroli dostępu użytkowników

Użyj getUserPrincpal() lub getGroupPrincipal() do tworzenia podmiotów zabezpieczeń przy użyciu podanego identyfikatora zewnętrznego.

Poniższy przykład pokazuje, jak uzyskać uprawnienia do pliku. Te uprawnienia 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();
  // ...
}

Ten fragment kodu pokazuje, jak utworzyć podmioty zabezpieczeń, które są właścicielami z użyciem 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 ten fragment kodu pokazuje, jak utworzyć podmioty zabezpieczeń, które czytelnicy pliku.

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 ją utworzyć:

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

Podstawowy interfejs API REST używa wzorca identitysources/IDENTITY_SOURCE_ID/users/EXTERNAL_ID dla identyfikatora przy tworzeniu podmiotów zabezpieczeń. W nawiązaniu do poprzednich tabel jeśli utworzysz listę ACL o nazwie id1_identity (SAMAccountName) Anny, identyfikator ten będzie ustaw jako:

identitysources/id1_identity/users/example/ann

Cały identyfikator jest nazywany identyfikatorem pośrednim użytkownika. ponieważ stanowi on pomost między identyfikatorem zewnętrznym a identyfikatorami Google zapisanymi w pamięci podręcznej. dzięki Cloud Directory.

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

Grupy map

Źródła tożsamości służą również jako przestrzeń nazw dla grup używanych na listach kontroli dostępu (ACL). Dostępne opcje użyj tej funkcji przestrzeni nazw do tworzenia i mapowania grup plików wykorzystywanych w celu zapewnienia bezpieczeństwa służą tylko do celów lub są lokalne dla repozytorium.

Użycie interfejsu Cloud Identity Groups API aby utworzyć grupę i zarządzać członkostwem. Aby powiązać grupę z źródła tożsamości, użyj nazwy zasobu źródła tożsamości jako przestrzeni nazw grupy.

Fragment kodu poniżej pokazuje, jak utworzyć grupę za pomocą atrybutu 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);
}

Tworzenie grupowej listy kontroli dostępu (ACL)

Aby utworzyć listę kontroli dostępu grupy, użyj getGroupPrincipal() do utworzenia podmiotu zabezpieczeń grupy przy użyciu podanego identyfikatora zewnętrznego. Następnie utwórz Lista ACL wykorzystująca Acl.Builder 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

Do tworzenia list kontroli dostępu i indeksowania elementów można używać zewnętrznych identyfikatorów (niepochodzących od Google), użytkownicy nie widzą elementów w wyszukiwaniu, dopóki ich identyfikatory zewnętrzne nie będą miały identyfikatorów Google Identyfikator w Cloud Directory. Są 3 sposoby, aby zapewnić Cloud Directory zna zarówno identyfikator Google, jak i identyfikatory zewnętrzne użytkownika:

ręcznie aktualizować poszczególne profile użytkowników w konsoli administracyjnej, Ten proces jest zalecany do testowania i tworzenia prototypów przy użyciu kilku profili użytkowników.
Zmapuj zewnętrzne identyfikatory na identyfikatory Google przy użyciu interfejsu Directory API. Ten proces jest zalecany dla osób, które nie mogą korzystać z pakietu Identity Connector SDK.
Tworzenie oprogramowania sprzęgającego tożsamości za pomocą Identity Connector SDK. Upraszcza on użycie interfejsu Directory API do mapowania identyfikatorów.

Oprogramowanie sprzęgające tożsamości to programy używane do mapowania zewnętrznych identyfikatorów firm tożsamości (użytkowników i grup) a wewnętrznymi tożsamościami Google używanymi przez Google, Cloud Search. Jeśli musisz utworzyć źródło tożsamości, musisz utworzyć oprogramowanie sprzęgające tożsamości.

Google Cloud Directory Sync (GCDS) to Przykład łącznika tożsamości. To oprogramowanie sprzęgające tożsamości mapuje użytkowników i grupować informacje z Active Directory firmy Microsoft do Cloud Directory z atrybutami użytkownika, które mogą reprezentować jego tożsamość w innych systemach.

Zsynchronizuj tożsamości przy użyciu interfejsu API REST

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

Mapowanie tożsamości

Po zmapowaniu tożsamości elementu z inną tożsamością musisz ponownie zindeksować elementy aby przejęła ona nową tożsamość. Na przykład

jeśli spróbujesz usunąć mapowanie z konta użytkownika lub ponownie je zmapować, oryginalne mapowanie jest zachowywane do czasu jego ponownego zindeksowania.
Jeśli usuniesz zmapowaną grupę, która znajduje się na liście kontroli dostępu elementu, a następnie utworzysz nowej grupy z tą samą wartością groupKey, nowa grupa nie zapewnia dostępu do do czasu jego ponownego zindeksowania.