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 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średniego dostępu do kont Google. Zamiast tego konta lokalne reprezentują użytkowników lub użytkownicy korzystają z logowania federacyjnego u dostawcy tożsamości. Ten identyfikator, inny niż adres e-mail, jest nazywany identyfikatorem zewnętrznym.

Źródła tożsamości utworzone za pomocą konsoli administracyjnej wypełniają lukę między systemami tożsamości przez:

• zdefiniowanie niestandardowego pola użytkownika do przechowywania identyfikatorów zewnętrznych. To pole rozpoznaje identyfikatory zewnętrzne jako konto Google.
• zdefiniowanie przestrzeni 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 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ść, oddzielając indeksowanie od mapowania tożsamości. Dzięki temu możesz odłożyć wyszukiwanie użytkowników podczas tworzenia list ACL i indeksowania elementów.

Przykładowe wdrożenie

Rysunek 1 przedstawia firmę korzystającą z repozytoriów lokalnych i w chmurze. Każde z nich używa innego typu identyfikatora zewnętrznego.

Rysunek 1. Przykładowe wdrożenie w firmie z różnymi typami tożsamości.

Repozytorium 1 identyfikuje użytkowników za pomocą adresu e-mail przy użyciu SAML. Ponieważ zna podstawowy adres e-mail w Google Workspace lub katalogu Cloud, nie potrzebuje źródła tożsamości.

Repozytorium 2 integruje się z katalogiem lokalnym i identyfikuje użytkowników za pomocą sAMAccountName. Ponieważ używa tego atrybutu jako identyfikatora zewnętrznego, wymaga źródła 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.

Utwórz źródło tożsamości przed utworzeniem łącznika treści. Będziesz potrzebować jego identyfikatora do tworzenia list ACL i indeksowania danych. Utworzenie źródła tożsamości powoduje też utworzenie niestandardowej właściwości użytkownika w katalogu Cloud do przechowywania identyfikatorów zewnętrznych. Nazwa właściwości jest zgodna z konwencją IDENTITY_SOURCE_ID_identity.

Ta tabela przedstawia 2 źródła tożsamości: jedno dla nazw kont SAM i jedno dla identyfikatorów użytkowników (uid).

Ź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 typu identyfikatora zewnętrznego używanego w Twojej firmie.

Ta tabela pokazuje, jak użytkownik z kontem Google i 2 identyfikatorami zewnętrznymi wygląda w katalogu Cloud:

Użytkownik	E-mail	id1_identity	id2_identity
Anna	[e-mail]	example\ann	1001

Podczas tworzenia list ACL na potrzeby indeksowania możesz odwoływać się do tego samego użytkownika za pomocą dowolnego z tych identyfikatorów.

Zapisywanie list ACL użytkowników

Użyj getUserPrincipal() lub getGroupPrincipal() , aby utworzyć podmioty zabezpieczeń za pomocą identyfikatorów zewnętrznych.

Ten przykład pobiera uprawnienia do pliku, w tym użytkowników z dostępem:

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 tworzy podmioty zabezpieczeń dla właścicieli za pomocą atrybutu externalUserName:

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

Ten fragment kodu tworzy podmioty zabezpieczeń dla czytelników:

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ż czytelników i właścicieli, utwórz listę ACL:

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

Interfejs API REST używa wzorca identitysources/IDENTITY_SOURCE_ID/users/EXTERNAL_ID. Anny id1_identity jest rozpoznawany jako identitysources/id1_identity/users/example/ann. Jest to identyfikator pośredni użytkownika.

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

Mapowanie grup

Źródła tożsamości służą też jako przestrzeń nazw dla grup list ACL. Użyj jej do tworzenia i mapowania grup używanych tylko do zabezpieczeń lub lokalnych w repozytorium.

Użyj interfejsu Cloud Identity Groups API aby tworzyć grupy i zarządzać członkostwem. Powiąż grupę ze źródłem tożsamości, używając nazwy źródła tożsamości jako przestrzeni nazw.

Ten fragment kodu tworzy grupę:

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 listy ACL grupy

Użyj getGroupPrincipal() , aby utworzyć podmiot zabezpieczeń grupy z identyfikatorem zewnętrznym, a następnie utwórz listę ACL:

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

Łączniki tożsamości

Użytkownicy nie widzą elementów w wynikach wyszukiwania, dopóki ich identyfikatory zewnętrzne nie zostaną rozpoznane jako identyfikator Google w katalogu Cloud. Możesz to zapewnić na 3 sposoby:

• Ręcznie zaktualizuj profile użytkowników w konsoli administracyjnej (zalecane tylko do testowania).
• Zmapuj identyfikatory za pomocą interfejsu Directory API.
• Utwórz łącznik tożsamości za pomocą pakietu Identity Connector SDK.

Łączniki tożsamości mapują identyfikatory zewnętrzne z tożsamości firmowych na wewnętrzne tożsamości Google. Jeśli utworzysz źródło tożsamości, musisz też utworzyć łącznik tożsamości.

Google Cloud Directory Sync (GCDS) Przykładem łącznika tożsamości jest. Mapuje on informacje o użytkownikach i grupach z Active Directory na katalog Cloud.

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

Do synchronizowania tożsamości użyj metody update.

Ponowne mapowanie tożsamości

Po ponownym zmapowaniu tożsamości musisz ponownie zindeksować elementy, aby zmiany zostały zastosowane.

• Jeśli usuniesz lub zmienisz mapowanie użytkownika, oryginalne mapowanie pozostanie do czasu ponownego indeksowania.
• Jeśli usuniesz zmapowaną grupę i utworzysz nową z tym samym groupKey, nie przyzna ona dostępu, dopóki nie przeprowadzisz ponownego indeksowania.