Mapear ACLs

Para garantir que apenas usuários com acesso a um item possam vê-lo em um resultado de pesquisa, é preciso indexar os itens com as respectivas listas de controle de acesso (ACLs, na sigla em inglês) no repositório corporativo. É preciso moldar as ACLs de seu repositório e inclui-las ao indexar itens nele. O SDK do Content Connector fornece um conjunto avançado de métodos de ACL capaz de moldar as ACLs da maioria dos repositórios.

Criar uma ACL

Esse é um processo de duas etapas:

  1. Crie um Principal usando métodos estáticos na classe ACL.
  2. Use a classe Acl.Builder para criar a ACL usando o principal.

No restante deste documento, são abordados alguns conceitos que você precisa conhecer para moldar e criar ACLs, como de herança e contenção.

Criar um principal usando um ID externo

O Google Cloud Search exige que usuários e grupos usem o endereço de e-mail do Google. Ao indexar itens do repositório, os conectores de conteúdo talvez não tenham esses endereços de e-mail. No entanto, o SDK do Content Connector permite usar qualquer ID externo (um ID que concede acesso a itens de repositório para um usuário ou grupo) em vez de um endereço de e-mail para indexar um item. Use o método getUserPrincipal() ou getGroupPrincpal() para criar principais contendo IDs externos. Existem vários outros métodos estáticos na classe ACL usados para criar objetos Principal.

Herança de ACL

Herança de ACL refere-se à autorização, para um item e um usuário específicos, com base no resultado de uma combinação das ACLs do item e das ACLs da cadeia de herança dele. As regras usadas para tomar uma decisão de autorização dependem do repositório e das propriedades do item.

Definir herança

Cada item pode ter principais permitidos diretos e principais negados diretos, especificados com os métodos setReaders() e setDeniedReaders(). Um principal permitido direto é um usuário identificado em uma ACL que fornece acesso direto a um item específico. Um principal negado direto é um usuário identificado em uma ACL como sem acesso a um item específico.

Um item também pode herdar principais permitidos indiretos e principais negados indiretos por meio do método setInheritFrom(). Um principal permitido indireto é um usuário que, por meio da herança de ACL, tem acesso indireto a um item específico. Um principal negado indireto é um usuário que, por meio da herança de ACL, tem acesso negado a um item específico.

A Figura 1 mostra como o método setInheritFrom() é usado para herdar principais permitidos indiretos e negados indiretos.

Desenho de conexões entre itens
Figura 1. Método setInheritFrom().

Os seguintes controles de acesso estão representados na Figura 1:

  • O usuário 1 é um principal permitido direto do item A.
  • O usuário 2 é um principal permitido direto do item B.
  • O item B herda a ACL do item A.

Veja a seguir as regras de acesso, com base nos controles de acesso:

  • Não é preciso especificar explicitamente o usuário 1 como principal do item B para que ele seja um principal permitido indireto desse item. O acesso é herdado porque o usuário 1 está listado como um principal direto permitido do item A e o item B herda a ACL do item A.
  • O usuário 2 não é um principal permitido indireto para o item A.

Definir tipo de herança

Se você definir herança usando o método setInheritFrom(), será preciso definir o tipo de herança usando o método setInheritanceType(). O tipo de herança determina como a ACL de um filho se combina com a ACL do pai. O método Acl.InheritanceType implementa três tipos de herança:

  • BOTH_PERMIT: defina o tipo de herança como BOTH_PERMIT para conceder ao usuário acesso ao item apenas quando a ACL do item filho e a ACL herdada do item do pai permitirem que o usuário o acesse.

  • CHILD_OVERRIDE: defina o tipo de herança como CHILD_OVERRIDE para forçar a precedência da ACL do item filho sobre a ACL herdada do item pai quando elas estiverem em conflito. Portanto, se a ACL do item pai negar o acesso ao usuário como um leitor negado, ele ainda terá acesso se tiver acesso ao item filho como leitor. Por outro lado, mesmo se a ACL do item pai conceder acesso ao usuário, ele não terá acesso se for um leitor negado do item filho.

  • PARENT_OVERRIDE: defina o tipo de herança como PARENT_OVERRIDE para forçar a precedência da ACL do item pai sobre a ACL do item filho quando elas estiverem em conflito. Portanto, se a ACL do item filho negar o acesso ao usuário como um leitor negado, ele ainda terá acesso se tiver acesso ao item pai como leitor. Por outro lado, mesmo se a ACL do item filho conceder acesso ao usuário, ele não terá acesso se for um leitor negado do item pai.

Avaliando a cadeia de herança de ACL, a ordem de avaliação pode alterar o resultado da decisão de autorização. O Cloud Search fornece uma ordem de avaliação das cadeias de herança de ACL "da folha para a raiz". A decisão da ACL por uma cadeia começa avaliando uma folha até a raiz, junto com seu respectivo pai.

Contenção e exclusão de itens

Ao indexar um item, é possível rotulá-lo como um contêiner usando o método setContainer() da classe IndexingItemBuilder. A relação entre o contêiner e o respectivo item estabelece a hierarquia física dos itens e garante que eles sejam excluídos corretamente. Quando um contêiner é excluído, os itens contidos nele também são excluídos.

As relações de contenção são totalmente independentes das regras de herança de ACL. Por exemplo, um arquivo em um sistema de arquivos pode estar contido em uma pasta para fins de exclusão, mas herdar a ACL de uma pasta diferente. A exclusão de uma pasta não exclui itens que herdam a ACL dela, a menos que esses itens também estejam na hierarquia de contenção da pasta.

Os seguintes controles de acesso estão representados na Figura 2:

  • O usuário 1 é um principal permitido direto do item A.
  • O usuário 2 é um principal permitido direto do item B.
  • O usuário 3 é um principal permitido direto do item C.
  • O item C herda a ACL do item A.
  • O item B nomeia o item A como o respectivo contêiner.
  • O item C nomeia o item B como o respectivo contêiner.

Veja a seguir as regras de acesso, com base nos controles de acesso:

  • O acesso indireto vem do método setInheritFrom(). Portanto, o usuário 1 pode acessar o item C, porque o item C herda a ACL do item A.
  • O acesso indireto não vem do item C contido no item B. Portanto, o usuário 2 não pode acessar o item C.
Desenho de conexões entre itens
Figura 2. Método setInheritFrom() em uso.

A separação da herança de ACL da hierarquia de contenção permite modelar muitas estruturas atuais diferentes.

Quando um item é excluído com sucesso:

  • Todos os itens que continham um item excluído se tornam não pesquisáveis e são agendados para exclusão da origem de dados do Google.
  • Todos os itens que especificaram o item excluído usando o método setInheritFrom() se tornam não pesquisáveis.

Se um recurso tiver um item excluído usando o método setInheritFrom(), mas não tiver um conjunto de contêineres usando setContainer(), ou se a respectiva hierarquia de contenção não contiver itens excluídos, o item e os dados dele permanecerão na origem de dados do Google. Você será responsável por excluí-lo.

A Figura 3 mostra um exemplo de como a exclusão funciona em uma hierarquia de itens.

Desenho de conexões entre itens
Figura 3. Como excluir um item e a herança de ACL.

Os seguintes controles de acesso estão representados na Figura 3:

  • O usuário 1 é um principal permitido direto do item A.
  • O usuário 2 é um principal permitido direto do item D.
  • O item D e o item E herdam a ACL do item A.
  • O item D nomeia o item A como contêiner.
  • Os itens A e E são itens de nível de raiz, porque não têm um item de contêiner.

Exclui a cascata por meio das referências do contêiner. Quando o item A é excluído:

  • Todos os descendentes da referência setInheritFrom() perdem o acesso de todos os usuários.
  • Nenhum usuário pode acessar o item A.
  • O item D é implicitamente excluído. Nenhum usuário poderá acessá-lo.
  • O item E não é excluído, porque a exclusão em cascata é feita apenas nas referências do contêiner.
  • O item E se torna inacessível e nenhum usuário poderá pesquisá-lo.