Mapear ACLs

Para garantir que apenas usuários com acesso a um item possam vê-lo nos resultados da pesquisa, indexe os itens com as respectivas listas de controle de acesso (ACLs) do repositório corporativo. É preciso modelar as ACLs do repositório e incluí-las ao indexar itens. O SDK do Content Connector oferece métodos para modelar as ACLs da maioria dos repositórios.

Observação: o SDK do Content Connector aceita ACLs de domínio único, mas não entre domínios. Não é possível conceder acesso a usuários e grupos fora da sua organização. As ACLs referentes a usuários ou grupos fora da sua organização não têm efeito.

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.

Este documento aborda conceitos 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 usem endereços 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 um 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 getGroupPrincipal para criar principais contendo IDs externos. A classe ACL inclui vários outros métodos estáticos para criar objetos Principal.

Observação: os usuários só vão ver itens nos resultados da pesquisa depois que o ID externo deles for sincronizado com a Conta do Google. Você pode usar um conector de identidade para sincronizar IDs externos de usuários ou grupos com um endereço de e-mail do Google. Para mais informações, consulte Criar um conector de identidade.

Depois de remapear a identidade de um item, é necessário reindexar os itens para que a nova identidade entre em vigor. Para mais informações, consulte Remapeamento de identidades.

Herança de ACL

Herança de ACL refere-se à autorização para um item e um usuário específicos com base nas ACLs combinadas do item e da cadeia de herança dele. As regras para 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 com acesso direto a um item. Um principal negado direto é um usuário identificado em uma ACL como sem acesso a um item.

Um item também pode herdar principais permitidos indiretos e principais negados indiretos usando o método setInheritFrom. Um principal permitido indireto tem acesso indireto a um item por meio da herança de ACL. Um principal negado indireto tem o acesso negado por herança.

Observação: se você definir a herança usando o método setInheritFrom, também precisará definir o tipo de herança usando o método setInheritanceType. Para informações sobre tipos de herança, consulte Definir tipo de herança.

A Figura 1 mostra como usar o método setInheritFrom para herdar principais.

Figura 1. O método setInheritFrom.

A Figura 1 representa estes controles de acesso:

• 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.

Com base nesses controles, as regras de acesso são:

• O usuário 1 é um principal permitido indireto do item B sem ser especificado explicitamente. O acesso é herdado do item A.
• O usuário 2 não é um principal permitido indireto do item A.

Definir tipo de herança

Se você definir a herança usando o método setInheritFrom, defina 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 de um pai. O Acl.InheritanceType implementa três tipos:

• BOTH_PERMIT: conceda acesso somente quando as ACLs filho e pai permitirem.
• CHILD_OVERRIDE: a ACL filha tem precedência sobre a ACL mãe em caso de conflito. Um usuário pode acessar a criança mesmo que o familiar responsável negue, ou ter o acesso negado mesmo que o familiar responsável permita.
• PARENT_OVERRIDE: a ACL principal tem precedência sobre a ACL secundária em caso de conflito.

O Cloud Search avalia as cadeias de herança de ACL da folha para a raiz. A avaliação começa com a criança e os familiares responsáveis e pode progredir até o familiar responsável principal.

Por exemplo, se a criança usa CHILD_OVERRIDE e o usuário tem acesso, o Cloud Search não precisa avaliar o responsável. No entanto, se a criança usa PARENT_OVERRIDE ou BOTH_PERMIT, o Cloud Search continua avaliando a 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. Essa relação estabelece a hierarquia física e garante a exclusão adequada. Quando você exclui um contêiner, os itens contidos nele também são excluídos.

As relações de contenção são independentes das regras de herança de ACL. Por exemplo, uma pasta pode conter um arquivo para fins de exclusão, mas o arquivo pode 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.

A Figura 2 representa estes controles de acesso:

• 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.

Com base nesses controles, as regras de acesso são:

• O acesso indireto vem do método setInheritFrom. O usuário 1 pode acessar o item C porque ele herda do item A.
• O acesso indireto não vem da contenção. O usuário 2 não pode acessar o item C.

Figura 2. O método setInheritFrom em uso.

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

Quando você exclui um item:

• Todos os itens que continham o item excluído se tornam não pesquisáveis e são agendados para exclusão.
• Todos os itens que especificam o item excluído em setInheritFrom se tornam não pesquisáveis.

Se um recurso usar setInheritFrom para um item excluído, mas não tiver um contêiner definido ou se a hierarquia não contiver itens excluídos, o item vai permanecer na fonte de dados. Você é responsável por excluí-lo.

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

Figura 3. Como excluir um item e a herança de ACL.

A Figura 3 representa estes controles de acesso:

• O usuário 1 é um principal permitido direto do item A.
• O usuário 2 é um principal permitido direto do item D.
• Os itens D e E herdam 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.

As exclusões são feitas em cascata nas referências de contêiner. Quando você exclui o item A:

• Todos os descendentes da referência setInheritFrom perdem o acesso.
• Os usuários não podem mais acessar o item A.
• O item D é implicitamente excluído e fica inacessível.
• O item E não é excluído, mas se torna inacessível e não pode ser pesquisado.