Mapear ACLs

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

Criar uma ACL

Esse é um processo de duas etapas:

  1. Crie uma 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, abordamos alguns conceitos que você precisa conhecer para modelar e criar ACLs, como herança e contenção.

Criar um principal usando um ID externo

O Google Cloud Search exige que usuários e grupos resolvam 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 a 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 que contenham IDs externos. Existem vários outros métodos estáticos na classe ACL usados para criar objetos Principal.

Herança de ACL

Herança da 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 diretamente, especificados usando 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 usando o 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. O 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 a herança usando o método setInheritFrom(), terá que 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 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 acesse o item.

  • 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 entram 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 entram 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". Especificamente, a decisão da ACL para uma cadeia começa com a avaliação de um filho com os pais e pode progredir até o pai raiz.

Por exemplo, se o filho tiver o tipo de herança CHILD_OVERRIDE e o usuário tiver acesso ao filho, o Drive não precisará avaliar o pai. No entanto, se o filho tiver PARENT_OVERRIDE ou BOTH_PERMIT, o Drive continuará avaliando a herança mais adiante na cadeia.

Contenção e exclusão de itens

Ao indexar um item, é possível rotular um item como um contêiner usando o método setContainer() da classe IndexingItemBuilder. A relação entre o contêiner e o conteúdo 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. O método setInheritFrom() em uso.

A separação da herança da 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 fonte 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 hierarquia de contenção não contiver itens excluídos, esse item e os dados dele permanecerão na fonte 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 da 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() perderão 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 pode pesquisá-lo.