Sincronizar diferentes sistemas de identidade

O controle de acesso no Google Cloud Search é baseado na Conta do Google do usuário. Ao indexar um conteúdo, é preciso que todas as ACLs dos itens sejam resolvidas para códigos de usuário ou de grupo válidos do Google (endereços de e-mail).

Em muitos casos, um repositório não tem conhecimento direto das Contas do Google. Em vez disso, as contas locais representam usuários, ou os usuários usam o login federado com um provedor de identidade. Essa identificação, que não é o endereço de e-mail, é chamada de ID externo.

Criadas com o Admin Console, as origens de identidade preenchem a lacuna entre os sistemas de identidade:

Definindo um campo de usuário personalizado para armazenar IDs externos. Esse campo resolve IDs externos para uma Conta do Google.
Definindo um namespace para grupos de segurança gerenciados por um repositório ou provedor de identidade.

Use origens de identidade quando:

O repositório não conhece o endereço de e-mail principal do usuário no Google Workspace ou no Google Cloud Directory.
O repositório define grupos de controle de acesso que não correspondem a grupos baseados em e-mail no Google Workspace.

As origens de identidade melhoram a eficiência ao desvincular a indexação do mapeamento de identidade. Isso permite adiar a pesquisa do usuário ao criar ACLs e indexar itens.

Exemplo de implantação

A Figura 1 mostra uma empresa que usa repositórios locais e na nuvem. Cada um usa um tipo diferente de ID externo.

O repositório 1 identifica os usuários por endereço de e-mail usando o SAML. Como ele conhece o endereço de e-mail principal no Google Workspace ou no Cloud Directory, não precisa de uma origem de identidade.

O repositório 2 se integra a um diretório local e identifica os usuários por sAMAccountName. Como ele usa esse atributo como um ID externo, requer uma origem de identidade.

Criar uma origem de identidade

Se você precisar de uma origem de identidade, consulte Mapear identidades de usuário no Cloud Search.

Crie a origem de identidade antes de criar um conector de conteúdo. Você precisa do ID dela para criar ACLs e indexar dados. A criação de uma origem de identidade também cria uma propriedade do usuário personalizada no Cloud Directory para armazenar IDs externos. O nome da propriedade usa a convenção IDENTITY_SOURCE_ID_identity.

Esta tabela mostra duas origens de identidade: uma para nomes de contas SAM e outra para IDs de usuário (uid).

Origem de identidade	Propriedade do usuário	ID externo
`id1`	`id1_identity`	`sAMAccountName`
`id2`	`id2_identity`	`uid`

Crie uma origem de identidade para cada tipo de ID externo usado na sua empresa.

Esta tabela mostra como um usuário com uma Conta do Google e dois IDs externos aparecem no Cloud Directory:

Usuário	E-mail	`id1_identity`	`id2_identity`
Ann	`ann@example.com`	`example\ann`	`1001`

É possível fazer referência ao mesmo usuário usando qualquer um desses IDs ao formar ACLs para indexação.

Escrever ACLs de usuário

Use getUserPrincipal() ou getGroupPrincipal() para criar principais usando IDs externos.

Este exemplo recupera permissões de arquivo, incluindo usuários com acesso:

FilePermissionSample.java

Ver no GitHub

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

Este snippet cria principais para proprietários usando o atributo externalUserName:

FilePermissionSample.java

Ver no GitHub

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

Este snippet cria principais para leitores:

FilePermissionSample.java

Ver no GitHub

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

Depois de ter leitores e proprietários, crie a ACL:

FilePermissionSample.java

Ver no GitHub

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

A API REST usa o padrão identitysources/IDENTITY_SOURCE_ID/users/EXTERNAL_ID. O id1_identity de Ann é resolvido para identitysources/id1_identity/users/example/ann. Esse é o ID intermediário do usuário.

Para mais informações sobre como modelar ACLs de repositório, consulte ACLs.

Mapear grupos

As origens de identidade também servem como namespace para grupos de ACL. Use isso para criar e mapear grupos usados apenas para segurança ou locais em um repositório.

Use a API Cloud Identity Groups (em inglês) para criar grupos e gerenciar associações. Associe o grupo a uma origem de identidade usando o nome da origem de identidade como namespace.

Este snippet cria um grupo:

CreateGroupCommand.java

Ver no GitHub

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

Criar uma ACL de grupo

Use getGroupPrincipal() para criar um principal de grupo com um ID externo e, em seguida, crie a ACL:

FilePermissionSample.java

Ver no GitHub

if (permissions.contains(PosixFilePermission.GROUP_READ)) {
  String externalGroupName = attrs.group().getName();
  Principal group = Acl.getGroupPrincipal(externalGroupName, identitySourceId);
  readers.add(group);
}

Conectores de identidade

Os usuários não poderão ver itens nos resultados da pesquisa até que os IDs externos deles sejam resolvidos para um ID do Google no Cloud Directory. É possível garantir isso de três maneiras:

Atualize manualmente os perfis de usuário no Admin Console (recomendado apenas para testes).
Mapeie IDs usando a API Directory.
Crie um conector de identidade usando o SDK do Identity Connector.

Os conectores de identidade mapeiam IDs externos de identidades empresariais para identidades internas do Google. Se você criar uma origem de identidade, também precisará criar um conector de identidade.

O Google Cloud Directory Sync (GCDS) é um exemplo de conector de identidade. Ele mapeia informações de usuários e grupos do Active Directory para o Cloud Directory.

Sincronizar identidades usando a API REST

Use o update método para sincronizar identidades.

Remapear identidades

Depois de remapear uma identidade, é necessário reindexar os itens para que a mudança entre em vigor.

Se você remover ou alterar um mapeamento de usuário, o mapeamento original vai permanecer até a reindexação.
Se você excluir um grupo mapeado e criar um novo com a mesma groupKey, ele não vai conceder acesso até que você reindexe.

Sincronizar diferentes sistemas de identidade Mantenha tudo organizado com as coleções Salve e categorize o conteúdo com base nas suas preferências.

Exemplo de implantação

Criar uma origem de identidade

Escrever ACLs de usuário

Mapear grupos

Criar uma ACL de grupo

Conectores de identidade

Sincronizar identidades usando a API REST

Remapear identidades

Sincronizar diferentes sistemas de identidade