Asignar listas de control de acceso

Aunque no es un requisito imprescindible, te recomendamos encarecidamente que indexes los elementos con sus listas de control de acceso (LCA) desde el repositorio de la empresa. De esta forma, te aseguras de que solo aquellos usuarios que tengan acceso a un elemento puedan verlo en los resultados de búsqueda. Para ello, debes modelar las LCA de tu repositorio e incluirlas cuando indexes elementos del repositorio. El SDK Content Connector proporciona un amplio conjunto de métodos suficientemente eficaces para modelar las LCA de la mayoría de los repositorios.

Crear una LCA

Para crear una LCA debes llevar a cabo dos pasos:

  1. Crear un objeto Principal usando métodos estáticos de la clase ACL.
  2. Utilizar la clase Acl.Builder para crear la LCA con la entidad principal.

En el resto de este documento abordamos algunos conceptos que necesitas saber para modelar y crear una LCA, como la herencia y los contenedores.

Crear una entidad principal con un ID externo

Google Cloud Search requiere que los usuarios y grupos estén asociados a una dirección de correo electrónico de Google. Cuando se indexan elementos del repositorio, es posible que los conectores de contenido no tengan estas direcciones de correo electrónico. Sin embargo, el SDK Content Connector te permite indexar un elemento mediante un ID externo (un ID que permite a un usuario o un grupo acceder a elementos del repositorio), en lugar de una dirección de correo electrónico. Usa los métodos getUserPrincipal() o getGroupPrincpal() para crear entidades principales que contengan ID externos. Hay otros métodos estáticos en la clase ACL que se pueden usar para crear objetos Principal.

Herencia de LCA

La herencia de las LCA es la autorización que se da a un elemento y un usuario específicos en función del resultado de combinar las LCA del elemento y las de su cadena de herencia. La decisión de autorización se determina con diferentes reglas según el repositorio y las propiedades del elemento.

Definir la herencia

Cada elemento puede tener entidades principales directas autorizadas y no autorizadas, que se especifican con los métodos setReaders() y setDeniedReaders(). Una entidad principal directa autorizada es un usuario identificado en una LCA que le da acceso directo a un elemento específico. Una entidad principal directa no autorizada es un usuario identificado en una LCA que no tiene acceso a un elemento específico.

Un elemento también puede heredar entidades principales indirectas autorizadas y no autorizadas mediante el método setInheritFrom(). Una entidad principal indirecta autorizada es un usuario que, a través de la herencia de LCA, tiene acceso indirecto a un elemento específico. Una entidad principal indirecta no autorizada es un usuario al que, a través de la herencia de LCA, se le deniega el acceso a un elemento específico.

En la imagen 1 se muestra cómo se utiliza el método setInheritFrom() para heredar entidades principales indirectas autorizadas y no autorizadas.

Dibujo de conexiones entre elementos
Imagen 1. Método setInheritFrom().

En la imagen 1 se muestran los siguientes controles de acceso:

  • El usuario 1 es una entidad principal directa autorizada del elemento A.
  • El usuario 2 es una entidad principal directa autorizada del elemento B.
  • El elemento B hereda la LCA del elemento A.

Según los controles de acceso, las reglas de acceso son las siguientes:

  • El usuario 1 no necesita especificarse explícitamente como entidad principal del elemento B para considerarse una entidad principal indirecta autorizada del elemento B; el acceso se hereda porque el usuario 1 aparece como una entidad principal directa autorizada del elemento A, y el elemento B hereda la LCA del elemento A.
  • Sin embargo, el usuario 2 no es una entidad principal indirecta autorizada para el elemento A.

Definir el tipo de herencia

Si defines la herencia con el método setInheritFrom(), deberás configurar el tipo de herencia con el método setInheritanceType(). El tipo de herencia se refiere a la regla que determina cómo se combina la LCA de un elemento secundario con la de su elemento principal. El método Acl.InheritanceType implementa estos tres tipos de herencia:

  • BOTH_PERMIT: si defines el tipo de herencia BOTH_PERMIT, el usuario solo podrá acceder al elemento si tanto la LCA del elemento secundario como la LCA heredada del elemento principal le conceden acceso a ese elemento.

  • CHILD_OVERRIDE: si defines el tipo de herencia CHILD_OVERRIDE, la LCA del elemento secundario tendrá prioridad sobre la LCA heredada del elemento principal, cuando ambas estén en conflicto. Por lo tanto, si la LCA del elemento principal impide el acceso al usuario porque no dispone de permisos de lectura, el usuario todavía podrá acceder si tiene permisos de lectura en el elemento secundario. A la inversa, incluso si la LCA del elemento principal concede acceso al usuario, este no podrá acceder si no tiene permisos de lectura en el elemento secundario.

  • PARENT_OVERRIDE: si defines el tipo de herencia PARENT_OVERRIDE, la LCA del elemento principal tendrá prioridad sobre la del elemento secundario, cuando ambas estén en conflicto. Por lo tanto, si la LCA del elemento secundario impide el acceso al usuario porque no dispone de permisos de lectura, el usuario todavía podrá acceder si tiene permisos de lectura en el elemento principal. A la inversa, incluso si la LCA del elemento secundario concede acceso al usuario, este no podrá acceder si no tiene permisos de lectura en el elemento principal.

Al evaluar una cadena de herencias de LCA, el orden de la evaluación puede cambiar el resultado de la decisión de autorización. Cloud Search proporciona un orden de evaluación de arriba a abajo de las cadenas de herencias de LCA. Para decidirse por una cadena, una LCA comienza evaluando un elemento secundario con su elemento principal, hasta llegar a la raíz.

Contenedores y eliminación de elementos

Al indexar un elemento, puedes etiquetarlo como contenedor utilizando el método setContainer() de la clase IndexingItemBuilder. La relación entre contenedor y elemento contenido se utiliza para definir la jerarquía física de los elementos, específicamente para gestionar adecuadamente su eliminación. Cuando se elimina un contenedor, también se eliminan los elementos que contiene.

Las relaciones de contenedores son totalmente independientes de las reglas de herencia de LCA. Por ejemplo, un archivo de un sistema de archivos puede estar contenido en una carpeta para gestionar su eliminación, pero heredar la LCA de otra carpeta. Al eliminar una carpeta no se eliminan los elementos que heredan su LCA, a menos que esos elementos también se encuentren en la jerarquía de contenedores de la carpeta.

En la imagen 2 se muestran los siguientes controles de acceso:

  • El usuario 1 es una entidad principal directa autorizada del elemento A.
  • El usuario 2 es una entidad principal directa autorizada del elemento B.
  • El usuario 3 es una entidad principal directa autorizada del elemento C.
  • El elemento C hereda la LCA del elemento A.
  • El elemento B designa el elemento A como su contenedor.
  • El elemento C designa el elemento B como su contenedor.

Según los controles de acceso, las reglas de acceso son las siguientes:

  • El acceso indirecto proviene del método setInheritFrom(). Por lo tanto, el usuario 1 puede acceder al elemento C porque este hereda la LCA del elemento A.
  • El acceso indirecto no proviene del elemento C, que está contenido en el elemento B. Por lo tanto, el usuario 2 no puede acceder al elemento C.
Dibujo de conexiones entre elementos
Imagen 2. Uso del método setInheritFrom()

Esta separación de las herencias de LCA de la jerarquía de contenedores permite modelar muchas estructuras diferentes.

Cuando se elimina un elemento:

  • Cualquier elemento que el elemento eliminado haya especificado en su contenedor no podrá buscarse y estará programado para eliminarse de la fuente de datos de Google.
  • Cualquier elemento que el elemento eliminado haya especificado utilizando el método setInheritFrom() se podrá buscar.

Si un recurso tiene un elemento eliminado mediante el método setInheritFrom(), pero no tiene un conjunto de contenedores con setContainer() o su jerarquía de contenedores no incluye elementos eliminados, el elemento en cuestión y sus datos se mantendrán en la fuente de datos de Google. Deberás encargarte de eliminarlo personalmente.

En la imagen 3 se muestra un ejemplo de cómo funciona la eliminación en una jerarquía de elementos.

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

En la imagen 3 se muestran los siguientes controles de acceso:

  • El usuario 1 es una entidad principal directa autorizada del elemento A.
  • El usuario 2 es una entidad principal directa autorizada del elemento D.
  • Los elementos D y E heredan la LCA del elemento A.
  • El elemento D designa el elemento A como su contenedor.
  • Los elementos A y E son elementos de nivel raíz, ya que no tienen un elemento contenedor.

Cadena de eliminaciones en las referencias del contenedor. Cuando se elimina el elemento A:

  • Todos los usuarios dejan de tener acceso a los descendientes de la referencia setInheritFrom().
  • Ningún usuario puede acceder al elemento A.
  • El elemento D se elimina implícitamente y ningún usuario puede acceder a él.
  • El elemento E no se elimina, ya que la eliminación solo se propaga a través de las referencias de los contenedores.
  • El elemento E deja de estar accesible y ningún usuario podrá buscarlo.