Mapear ACLs

Para garantir que apenas usuários com acesso a um item possam vê-lo em um resultado da 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 inclua essas ACLs ao indexar itens no repositório. Conector de conteúdo O SDK fornece um conjunto avançado de métodos de ACL potentes o suficiente para modelar as ACLs de na maioria dos repositórios.

Criar uma ACL

Esse é um processo de duas etapas:

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

O restante do documento aborda alguns conceitos que você precisa saber para criar modelos 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 (ID que concede a um usuário ou grupo acesso aos itens do repositório), em vez disso de um endereço de e-mail para indexar um item. Use o getUserPrincipal() ou o getGroupPrincpal() para criar principais contendo IDs externos. Existem várias outras métodos estáticos na ACL usada para criar Principal.

Herança de ACL

Herança de ACL refere-se à autorização para um item específico e um com base no resultado de uma combinação das ACLs do item e das ACLs da cadeia de herança. 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, especificado usando o valor-chave 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 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 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 setInheritFrom() é necessário definir o tipo de herança usando o método setInheritanceType() . O tipo de herança determina como a A ACL é combinada 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 o filho que a ACL do item tenha precedência sobre a ACL herdada do item pai quando elas conflitos. 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 a ACL do item pai tenha precedência sobre a ACL do item filho quando ele conflitos. 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 de 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 Google Drive não precisará avaliar o pai. No entanto, se a criança tiver PARENT_OVERRIDE ou BOTH_PERMIT, o Google Drive continuará na avaliação da herança mais acima na cadeia.

Contenção e exclusão de itens

Ao indexar um item, é possível usá-lo para identificá-lo como um contêiner Método setContainer() da IndexingItemBuilder . A relação entre contêiner/contínuo estabelece a 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 de 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 que você modele muitas estruturas existentes 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.
• Qualquer item que tenha especificado o item excluído usando a propriedade Método setInheritFrom() se torna não pesquisável.

Se um recurso tiver um item excluído usando a propriedade setInheritFrom() método, mas não tem um conjunto de contêineres usando setContainer() ou a hierarquia de contenção não contém itens excluídos, o item e os dados dele permanece 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.

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 de setInheritFrom() referência perde 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 fica inacessível, e nenhum usuário consegue pesquisá-lo.