Asigna las LCA

Para garantizar que solo los usuarios con acceso a un elemento puedan verlo dentro de un resultado de búsqueda, debes indexar los elementos con sus listas de control de acceso (LCA) desde el repositorio de la empresa. Debes modelar las LCA del repositorio y, luego, incluirlas cuando indexas elementos en el repositorio. El SDK de conector de contenido proporciona un amplio conjunto de métodos de LCA que tienen la potencia suficiente para modelar las LCA de la mayoría de los repositorios.

Crea una LCA

La creación de una LCA es un proceso de dos pasos:

  1. Crea un Principal con métodos estáticos en la clase LCA.
  2. Usa la clase Acl.Builder para compilar la LCA mediante el principal.

En el resto de este documento, se describen algunos conceptos que necesitas para modelar y crear LCA, como herencia y contención.

Crea un principal con un ID externo

Google Cloud Search requiere que los usuarios y grupos resuelvan las direcciones de correo electrónico de Google. Cuando se indexan elementos de repositorios, es posible que los conectores de contenido no tengan estas direcciones de correo electrónico. Sin embargo, el SDK de conector de contenido te permite usar cualquier ID externo (ID que otorga a un usuario o grupo el acceso a los elementos de un repositorio) en lugar de una dirección de correo electrónico, para indexar un elemento. Usa el método getUserPrincipal() o getGroupPrincpal() para crear principales que contengan ID externos. Hay muchos otros métodos estáticos en la clase ACL que se usan para compilar objetos Principal.

Herencia de LCA

La herencia de LCA se refiere a la autorización de un elemento y un usuario específicos, en función del resultado de una combinación de las LCA del elemento y las de su cadena de herencia. Las reglas usadas para tomar una decisión de autorización dependen del repositorio y las propiedades del elemento.

Configura la herencia

Cada elemento puede tener principales permitidos directos y principales denegados directos, especificados con los métodos setReaders() y setDeniedReaders(). Un principal permitido directo es un usuario identificado en una LCA que otorga acceso directo a un elemento específico. Un principal denegado directo es un usuario identificado en una LCA sin acceso a un elemento específico.

También es posible que un elemento herede principales permitidos indirectos y principales denegados indirectos con el método setInheritFrom(). Un principal permitido indirecto es un usuario que, mediante la herencia de LCA, tiene acceso indirecto a un elemento específico. Un principal denegado indirecto es un usuario que, a través de una herencia de LCA, no tiene acceso a un elemento específico.

En la Figura 1, se muestra cómo se usa el método setInheritFrom() para heredar los principales permitidos indirectos y los principales denegados indirectos.

Dibujo de conexiones entre elementos
Figura 1. El método setInheritFrom().

Estos controles de acceso se representan en la Figura 1:

  • El usuario 1 es un principal permitido directo del elemento A.
  • El usuario 2 es un principal permitido directo del elemento B.
  • El elemento B hereda la LCA del elemento A.

A continuación, se detallan las reglas de acceso según los controles de acceso.

  • No es necesario especificar el usuario 1 de forma explícita como un principal del elemento B para que sea un principal permitido indirecto del elemento B. El acceso se hereda porque el usuario 1 se enumera como un principal permitido directo del elemento A y el elemento B hereda su LCA del elemento A.
  • Sin embargo, el usuario 2 no es un principal permitido indirecto del elemento A.

Configura el tipo de herencia

Si estableces la herencia con el método setInheritFrom(), debes establecer el tipo de herencia con el método setInheritanceType(). El tipo de herencia determina cómo se combina la LCA de un secundario con la LCA de su superior. Acl.InheritanceType implementa tres tipos de herencia:

  • BOTH_PERMIT: configura el tipo de herencia como BOTH_PERMIT para otorgar al usuario el acceso al elemento solo cuando la LCA del elemento secundario y la LCA del elemento heredado superior permiten al usuario acceder a ese elemento.

  • CHILD_OVERRIDE: configura el tipo de herencia como CHILD_OVERRIDE para forzar la LCA del elemento secundario a fin de que tenga prioridad sobre la LCA del elemento superior cuando entran en conflicto. Entonces, si la LCA del elemento superior niega el acceso al usuario como lector denegado, el usuario aún podrá acceder si tiene acceso al elemento secundario como lector. En cambio, aunque la LCA del elemento superior otorgue acceso al usuario, este no tendrá acceso si es un lector denegado del elemento secundario.

  • PARENT_OVERRIDE: establece el tipo de herencia como PARENT_OVERRIDE para forzar la LCA del elemento superior a fin de que tenga prioridad sobre la LCA del elemento secundario cuando entran en conflicto. Entonces, si la LCA del elemento secundario niega el acceso al usuario como lector denegado, el usuario aún podrá acceder si tiene acceso al elemento superior como lector. En cambio, aunque la LCA del elemento secundario otorgue acceso al usuario, este no tendrá acceso si es un lector denegado del elemento superior.

Cuando evalúes la cadena de herencia de una LCA, el orden de evaluación puede cambiar el resultado de la decisión de autorización. Cloud Search proporciona un orden de evaluación tipo árbol para las cadenas de herencia de LCA. La decisión de LCA para una cadena comienza con una evaluación de un secundario y su superior hasta llegar a la raíz.

Contención y eliminación de elementos

Cuando indexas un elemento, puedes etiquetarlo como contenedor con el método setContainer() de la clase IndexingItemBuilder. La relación entre el contenedor y su contenido establece la jerarquía física de los elementos y garantiza su correcta eliminación. Cuando se borra un contenedor, también se borran los elementos en él.

Las relaciones de contención son independientes de las reglas de herencia de LCA. Por ejemplo, una carpeta para eliminación puede contener un archivo en el sistema de archivos, pero este archivo hereda la LCA de una carpeta diferente. Borrar una carpeta no borra los elementos que hereda la LCA, a menos que esos elementos también estén en la jerarquía de contención de la carpeta.

En la figura 2, se representan los siguientes controles de acceso:

  • El usuario 1 es un principal permitido directo del elemento A.
  • El usuario 2 es un principal permitido directo del elemento B.
  • El usuario 3 es un principal permitido directo del elemento C.
  • El elemento C hereda la LCA del elemento A.
  • El elemento B nombra al elemento A como su contenedor.
  • El elemento C nombra al elemento B como su contenedor.

A continuación, se detallan las reglas de acceso según los controles de acceso.

  • El acceso indirecto viene del método setInheritFrom(). Por lo tanto, el usuario 1 puede acceder al elemento C porque hereda la LCA del elemento A.
  • El acceso indirecto no viene del elemento C contenido por el elemento B. Por lo tanto, el usuario 2 no tiene acceso al elemento C.
Dibujo de conexiones entre elementos
Figura 2. Método setInheritFrom() en uso.

La separación de la herencia de la LCA de la jerarquía de contención te permite modelar muchas estructuras existentes diferentes.

A continuación, se detalla lo que sucede cuando se borra un elemento de forma correcta:

  • Cualquier elemento que contenía un elemento borrado no se puede buscar y se programa para la eliminación de la fuente de datos de Google.
  • Cualquier elemento que especificó el elemento borrado con el método setInheritFrom() no se puede buscar.

Si un recurso tiene un elemento que se borró con el método setInheritFrom(), pero no tiene un conjunto de contenedores mediante setContainer(), o su jerarquía de contención no tiene elementos borrados, ese elemento y sus datos permanecen en la fuente de datos de Google. Deberás borrar el elemento.

En la figura 3, se muestra un ejemplo sobre cómo funciona la eliminación de una jerarquía de elemento.

Dibujo de conexiones entre elementos
Figura 3. Eliminación de un elemento y herencia de la LCA.

En la figura 3, se representan los controles de acceso:

  • El usuario 1 es un principal permitido directo del elemento A.
  • El usuario 2 es un principal permitido directo del elemento D.
  • Los elementos D y E heredan la LCA del elemento A.
  • El elemento D nombra al elemento A como su contenedor.
  • Los elementos A y E están a nivel raíz, ya que no tienen un elemento contenedor.

Eliminados en cascada mediante las referencias del contenedor. Cuando se borra el elemento A, sucede lo siguiente:

  • Todos los descendientes de la referencia setInheritFrom() pierden el acceso para todos los usuarios.
  • Ningún usuario puede obtener acceso al elemento A.
  • El elemento D se borra de forma implícita. Ningún usuario puede tener acceso al elemento D.
  • El elemento E no se borra, ya que la eliminación solo se hace en cascada a través de las referencias del contenedor.
  • El elemento E no se puede buscar y ningún usuario puede buscarlo.