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 produktów muszą być zgodne z prawidłowymi identyfikatorami użytkowników lub grup (adresami 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 wykorzystywać do identyfikowania kont logowanie sfederowane z użyciem dostawcy tożsamości i identyfikatora innych niż adres e-mail użytkownika. Jest on nazywany identyfikatorem zewnętrznym.

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

• Zdefiniuj niestandardowe pole użytkownika do przechowywania identyfikatorów zewnętrznych. To pole służy do znajdowania identyfikatorów zewnętrznych na koncie 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 podstawowym adresie e-mail użytkownika w Google Workspace ani Google Cloud Directory.
• Repozytorium definiuje grupy na potrzeby kontroli dostępu, które nie odpowiadają grupom opartym na adresach e-mail w Google Workspace.

Źródła tożsamości poprawiają efektywność indeksowania, oddzielając indeksowanie od 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

Rysunek 1 przedstawia przykładowe wdrożenie, w którym organizacja używa zarówno repozytoriów lokalnych, jak i repozytoriów w chmurze. Każde repozytorium używa do odwoływania się do użytkowników innego typu identyfikatorów zewnętrznych.

Repozytorium 1 identyfikuje użytkownika przy użyciu adresu e-mail zarejestrowanego za pomocą 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 na podstawie atrybutu sAMAccountName. Jako identyfikator zewnętrzny repozytorium 2 używa atrybutu sAMAccountName, 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, 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ż będziesz potrzebować identyfikatora źródła tożsamości do tworzenia list kontroli dostępu i danych indeksu. Jak wspomnieliśmy wcześniej, utworzenie źródła tożsamości powoduje też utworzenie niestandardowej właściwości użytkownika w Cloud Directory. Ta właściwość pozwala rejestrować zewnętrzny identyfikator każdego użytkownika w repozytorium. Właściwość nosi nazwę zgodnie z konwencją IDENTITY_SOURCE_ID_identity.

W tabeli poniżej znajdziesz 2 źródła tożsamości. Jedno zawiera nazwy kont SAM (sAMAccountName) jako identyfikatory zewnętrzne, a drugie uid jako identyfikatory zewnętrzne.

Utwórz źródło tożsamości dla każdego możliwego identyfikatora zewnętrznego używanego do odwoływania 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 i id2_identity) oraz z ich wartościami wyświetlają się w Cloud Directory:

Podczas tworzenia list kontroli dostępu do indeksowania do indeksowania możesz odwołać się do tego samego użytkownika, używając trzech różnych identyfikatorów (adres e-mail Google, sAMAccountName i uid).

Zapisywanie list kontroli dostępu użytkowników

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

Poniższy przykład pokazuje, jak uzyskać uprawnienia do pliku. Obejmują one nazwy wszystkich użytkowników, którzy mają 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 przy użyciu identyfikatora zewnętrznego (externalUserName) zapisanych w atrybutach utworzyć podmioty zabezpieczeń będące właścicielami.

// 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 z poniższego fragmentu kodu dowiesz się, jak utworzyć podmioty zabezpieczeń, które odczytują plik.

// 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ć:

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

Bazowy interfejs API REST podczas tworzenia podmiotów zabezpieczeń używa wzorca identitysources/IDENTITY_SOURCE_ID/users/EXTERNAL_ID dla identyfikatora. Nawiązując do poprzednich tabel, jeśli utworzysz listę kontroli dostępu (ACL) z identyfikatorem id1_identity (SAMAccountName) Anny, identyfikator ten będzie wskazywać:

identitysources/id1_identity/users/example/ann

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

Więcej informacji o modelowaniu list kontroli dostępu używanych w 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). Za pomocą tej funkcji przestrzeni nazw możesz tworzyć i mapować grupy, które są używane tylko do celów związanych z bezpieczeństwem lub są lokalne dla repozytorium.

Użyj interfejsu Cloud Identity Groups API do utworzenia grupy i zarządzania członkostwem. 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.

Poniższy 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 grupowej listy kontroli dostępu (ACL)

Aby utworzyć listę kontroli dostępu grupy, użyj metody getGroupPrincipal() i utwórz podmiot zabezpieczeń grupy z podanym identyfikatorem zewnętrznym. Następnie utwórz listę kontroli dostępu (ACL) za pomocą klasy Acl.Builder w następujący 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

Chociaż do tworzenia list kontroli dostępu i elementów indeksu możesz używać zewnętrznych identyfikatorów niepochodzących od Google, użytkownicy nie będą widzieć elementów w wyszukiwaniu, dopóki ich identyfikatory zewnętrzne nie będą miały identyfikatora Google w Cloud Directory. Są 3 sposoby na to, aby mieć pewność, że Cloud Directory zna zarówno identyfikator Google, jak i identyfikatory zewnętrzne użytkownika:

• Ręczne aktualizowanie poszczególnych profili użytkowników w konsoli administracyjnej Ten proces jest zalecany tylko w przypadku 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.
• Utwórz oprogramowanie sprzęgające tożsamości za pomocą pakietu SDK Identity Connector. Upraszcza on użycie interfejsu Directory API do mapowania identyfikatorów.

Oprogramowanie sprzęgające tożsamości to programy służące do mapowania zewnętrznych identyfikatorów z tożsamości firm (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 utworzyć oprogramowanie sprzęgające tożsamości.

Przykładem łącznika tożsamości jest Google Cloud Directory Sync (GCDS). Oprogramowanie sprzęgające tożsamości mapuje informacje o użytkownikach i grupach z 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 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 uzyskać dostęp do nowej tożsamości. Na przykład

• Jeśli spróbujesz usunąć mapowanie z konta użytkownika lub ponownie je zmapować, oryginalne mapowanie zostanie zachowane do czasu ponownego zindeksowania.
• Jeśli usuniesz zmapowaną grupę, która znajduje się na liście kontroli dostępu produktu, a następnie utworzysz nową grupę z tym samym identyfikatorem groupKey, nowa grupa nie zapewni dostępu do elementu, dopóki ten element nie zostanie ponownie zindeksowany.