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 to identyfikator zewnętrzny.

Ź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ść przez oddzielenie indeksowania 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

Ilustracja 1 przedstawia 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. Będziesz potrzebować jego identyfikatora do utworzenia list ACL i indeksowania danych. 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.

Ta tabela zawiera 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 pokazujemy, 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 symbolu  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ż osoby z uprawnieniami do odczytu 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 mapować grupy używane tylko na potrzeby zabezpieczeń lub lokalne w repozytorium.

Do tworzenia grup i zarządzania członkostwem w nich używaj interfejsu 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 Directory. Możesz to zrobić na 3 sposoby:

• Ręcznie aktualizuj profile użytkowników w konsoli administracyjnej (zalecane tylko w przypadku testów).
• 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ć łącznik 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 zmiana została zastosowana.

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