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, nazywa się identyfikatorem zewnętrznym.

Źródła tożsamości utworzone w konsoli administracyjnej wypełniają lukę między systemami tożsamości, ponieważ:

• Zdefiniuj niestandardowe pole użytkownika, aby przechowywać identyfikatory zewnętrzne. To pole przekształca identyfikatory zewnętrzne na konto Google.
• Określanie przestrzeni nazw dla grup zabezpieczeń zarządzanych przez repozytorium lub dostawcę tożsamości.

Korzystaj ze ź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

Na rysunku 1 przedstawiono firmę korzystającą z repozytoriów lokalnych i w chmurze. Każdy z nich używa innego typu zewnętrznego identyfikatora.

Rysunek 1. Przykład wdrożenia 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 Cloud Directory, nie potrzebuje źródła tożsamości.

Repozytorium 2 jest zintegrowane 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, zapoznaj się z artykułem Mapowanie tożsamości użytkowników w Cloud Search.

Utwórz źródło tożsamości przed utworzeniem łącznika treści. Aby utworzyć listy ACL i zindeksować dane, potrzebujesz jego identyfikatora. Utworzenie źródła tożsamości powoduje też utworzenie w Cloud Directory niestandardowej właściwości użytkownika, w której będą przechowywane identyfikatory zewnętrzne. Nazwa właściwości jest zgodna z konwencją IDENTITY_SOURCE_ID_identity.

W tej tabeli przedstawiono 2 źródła tożsamości: jedno dla nazw kont SAM, a drugie 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 zewnętrznego identyfikatora używanego w Twojej firmie.

W tej tabeli pokazano, jak użytkownik z kontem Google i 2 zewnętrznymi identyfikatorami wygląda w Cloud Directory:

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 przy użyciu 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 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 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. Adres id1_identity Anny przyjmuje wartość identitysources/id1_identity/users/example/ann. Jest to identyfikator pośredni użytkownika.

Więcej informacji o modelowaniu list kontroli dostępu do repozytorium znajdziesz w artykule Listy kontroli dostępu.

Mapowanie grup

Źródła tożsamości służą też jako przestrzeń nazw dla grup ACL. Użyj tej opcji, aby utworzyć i zmapować grupy używane tylko na potrzeby zabezpieczeń lub lokalne w repozytorium.

Do tworzenia grup i zarządzania członkostwem w nich służy Cloud Identity Groups API. 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 grupy z zewnętrznym identyfikatorem, a następnie zbudować 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);
}

Oprogramowanie sprzęgające tożsamości

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

• Ręcznie aktualizuj profile użytkowników w konsoli administracyjnej (zalecane tylko w przypadku testów).
• Mapuj identyfikatory map za pomocą interfejsu Directory API.
• Utwórz łącznik tożsamości za pomocą pakietu SDK łącznika tożsamości.

Łączniki tożsamości mapują zewnętrzne identyfikatory tożsamości biznesowych na wewnętrzne tożsamości Google. Jeśli utworzysz źródło tożsamości, musisz też utworzyć oprogramowanie sprzęgające tożsamości.

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

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

używaj metody update do synchronizowania tożsamości.

Ponowne mapowanie tożsamości

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

• Jeśli usuniesz lub zmienisz mapowanie użytkownika, pierwotne mapowanie pozostanie do czasu ponownego indeksowania.
• Jeśli usuniesz zmapowaną grupę i utworzysz nową z tym samymgroupKey, nie przyznasz dostępu, dopóki nie przeprowadzisz ponownej indeksacji.