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 ACL dotyczące elementów muszą być rozpoznawane jako prawidłowe identyfikatory użytkowników lub grup Google (adresy 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 korzystać z logowania federacyjnego za pomocą dostawcy tożsamości i identyfikatora innego niż adres e-mail użytkownika, aby identyfikować poszczególne konta. Ten identyfikator jest nazywany identyfikatorem zewnętrznym.

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

• Zdefiniuj niestandardowe pole użytkownika, aby przechowywać identyfikatory zewnętrzne. To pole służy do przypisywania identyfikatorów zewnętrznych do konta Google.
• Określ przestrzeń nazw dla grup zabezpieczeń zarządzanych przez repozytorium lub dostawcę tożsamości.

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

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

Źródła tożsamości zwiększają wydajność indeksowania, oddzielając indeksowanie od mapowania tożsamości. To rozdzielenie pozwala odłożyć 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 firma korzysta zarówno z repozytoriów lokalnych, jak i chmurowych. 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ą SAML. Ponieważ repozytorium 1 zna podstawowy adres e-mail użytkownika w Google Workspace lub Cloud Directory, nie jest potrzebne źródło tożsamości.

Repozytorium 2 jest bezpośrednio zintegrowane z katalogiem lokalnym i identyfikuje użytkownika na podstawie atrybutu sAMAccountName. Ponieważ repozytorium 2 używa atrybutu sAMAccountName jako identyfikatora zewnętrznego, 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 łącznika treści musisz utworzyć źródło tożsamości, ponieważ do utworzenia list ACL i indeksowania danych potrzebny będzie identyfikator źródła tożsamości. Jak wspomnieliśmy wcześniej, utworzenie źródła tożsamości powoduje też utworzenie w katalogu Cloud niestandardowej właściwości użytkownika. Użyj tej właściwości, aby rejestrować w repozytorium zewnętrzny identyfikator każdego użytkownika. Nazwa właściwości jest zgodna z konwencją IDENTITY_SOURCE_ID_identity.

W tabeli poniżej przedstawiono 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.

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 organizacji.

W poniższej tabeli pokazano, jak użytkownik z kontem Google i 2 zewnętrznymi identyfikatorami (id1_identity i id2_identity) oraz ich wartościami pojawia się w Cloud Directory:

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

Zapisywanie list ACL użytkowników

Użyj metody getUserPrincpal() lub getGroupPrincipal(), aby utworzyć podmioty przy użyciu podanego identyfikatora zewnętrznego.

Poniższy przykład pokazuje, jak pobrać uprawnienia dotyczące 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();
  // ...
}

Poniższy fragment kodu pokazuje, jak utworzyć podmioty, które są 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 mogą odczytywać 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ę osób z uprawnieniami do odczytu 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();

Podstawowy interfejs API REST używa wzorca identitysources/IDENTITY_SOURCE_ID/users/EXTERNAL_ID do tworzenia identyfikatorów podmiotów. Wracając do poprzednich tabel, jeśli utworzysz listę ACL z użyciem id1_identity (SAMAccountName) Anny, identyfikator zostanie rozpoznany jako:

identitysources/id1_identity/users/example/ann

Cały ten identyfikator jest nazywany identyfikatorem pośrednim użytkownika, ponieważ stanowi pomost między identyfikatorem zewnętrznym a identyfikatorami Google przechowywanymi w Cloud Directory.

Więcej informacji o modelowaniu list ACL używanych w repozytorium znajdziesz w artykule Listy ACL.

Mapowanie grup

Źródła tożsamości służą też jako przestrzeń nazw dla grup używanych w listach 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 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.

Poniższy fragment kodu pokazuje, jak utworzyć grupę za pomocą 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ć listę ACL grupy, użyj metody getGroupPrincipal(), aby utworzyć podmiot grupy za pomocą podanego identyfikatora zewnętrznego. Następnie utwórz listę 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żesz używać zewnętrznych identyfikatorów innych niż Google, ale użytkownicy nie będą widzieć elementów w wyszukiwarce, dopóki ich zewnętrzne identyfikatory nie zostaną rozpoznane jako identyfikatory Google w katalogu Cloud. Istnieją 3 sposoby, aby zapewnić, że Cloud Directory zna zarówno identyfikator Google, jak i identyfikatory zewnętrzne użytkownika:

• Ręcznie zaktualizuj 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 dla osób, 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 Directory API do mapowania identyfikatorów.

Łączniki tożsamości to programy służące do mapowania zewnętrznych identyfikatorów tożsamości przedsiębiorstwa (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.

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 katalog 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

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

Ponowne mapowanie tożsamości

Po ponownym przypisaniu tożsamości produktu do innej tożsamości musisz ponownie zindeksować produkty, aby nowa tożsamość została zastosowana. Na przykład

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