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:
- Crie um
Principal
usando métodos estáticos no ACL . - 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.
![Desenho de conexões entre itens](https://developers.google.cn/static/cloud-search/images/inherit-from-SDK.png?authuser=0000&hl=pt)
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
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 comoBOTH_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 comoCHILD_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 comoPARENT_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.
![Desenho de conexões entre itens](https://developers.google.cn/static/cloud-search/images/doc-hierarchy-SDK.png?authuser=0000&hl=pt)
setInheritFrom()
em uso.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.
![Desenho de conexões entre itens](https://developers.google.cn/static/cloud-search/images/doc-hierarchy-deletion-SDK.png?authuser=0000&hl=pt)
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.