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) do repositório corporativo. É preciso modelar as ACLs do repositório e incluí-las ao indexar itens nele. 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 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, abordamos alguns conceitos que você precisa conhecer para modelar 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 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 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 o método getGroupPrincpal() para criar principais contendo IDs externos. Há vários outros métodos estáticos na classe ACL usada 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 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.

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(), 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 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 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". 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é a raiz.

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

Contenção e exclusão de itens

Ao indexar um item, você pode marcá-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.

A separação da herança de ACL da hierarquia de contenção permite modelar muitas estruturas 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 contêiner definido usando setContainer() ou se a hierarquia de contenção não contiver itens excluídos, o item e os dados dele vão permanecer 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.

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 pode pesquisar o item E.