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 de tu repositorio y, luego, incluirlas cuando indexes los elementos en el repositorio. El SDK de Content Connector proporciona un amplio conjunto de métodos de LCA lo suficientemente eficaces para dar forma a las LCA de la mayoría de los repositorios.

Nota: El SDK de Content Connector admite LCA de dominio único, pero no de dominio cruzado. No puedes otorgar acceso a los usuarios y grupos fuera de la organización. Las LCA que hagan referencia a usuarios o grupos ajenos a la organización no tienen efecto.

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 ACL.
2. Usa la clase Acl.Builder para compilar la LCA con 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 los 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 el método getGroupPrincpal() para crear principales que contengan IDs externos. Hay varios otros métodos estáticos en la clase ACL que se usan para compilar objetos Principal.

Nota: Los usuarios no verán los elementos en los resultados de la búsqueda hasta que el ID externo se sincronice con su Cuenta de Google. La sincronización de estos ID externos de usuarios o grupos con la dirección de correo electrónico de Google se puede realizar con un conector de identidad. Para obtener más información sobre los conectores de identidad, consulta Crea un conector de identidad.

Advertencia: Después de volver a asignar la identidad de un elemento a otra, debes volver a indexar los elementos para que se aplique la identidad nueva. Para obtener más información, consulta Cómo reasignar identidades.

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, que se especifican con los métodos setReaders() y setDeniedReaders(). Un principal permitido directo es un usuario identificado en una LCA que le 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, mediante una herencia de LCA, no tiene acceso a un elemento específico.

Nota: Si configuras la herencia con el método setInheritFrom(), debes establecer el tipo de herencia con el método setInheritanceType(). Para obtener información sobre los tipos de herencia, consulta Configura el tipo de herencia.

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.

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 está detallado 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 configuras la herencia con el método setInheritFrom(), debes configurar 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 para BOTH_PERMIT a fin de otorgar al usuario el acceso al elemento solo cuando la LCA del elemento secundario y la LCA del elemento heredado principal permiten al usuario el acceso a ese elemento.

• CHILD_OVERRIDE: establece el tipo de herencia como CHILD_OVERRIDE para forzar la LCA del elemento secundario con el objetivo de que tenga prioridad sobre la LCA del elemento superior cuando entran en conflicto. Es decir, si la LCA del elemento principal rechaza el acceso al usuario como lector denegado, el usuario seguirá teniendo acceso si tiene acceso al elemento secundario como lector. En cambio, aunque la LCA del elemento principal otorgue acceso al usuario, este no tendrá acceso si es un lector denegado del elemento secundario.

• PARENT_OVERRIDE: establece el tipo de herencia para PARENT_OVERRIDE a fin de forzar la LCA del elemento superior con el objetivo de que tenga prioridad sobre la LCA del elemento secundario cuando entran en conflicto. Es decir, si la LCA del elemento secundario rechaza el acceso al usuario como lector denegado, el usuario seguirá teniendo acceso si tiene acceso al elemento principal 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 principal.

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. Específicamente, la decisión de LCA para una cadena comienza con la evaluación de un secundario con sus superiores y puede avanzar hasta el superior raíz.

Por ejemplo, si el elemento secundario tiene el tipo de herencia CHILD_OVERRIDE y el usuario tiene acceso a él, Drive no necesita evaluar el elemento superior. Sin embargo, si el elemento secundario tiene PARENT_OVERRIDE o BOTH_PERMIT, Drive continúa evaluando la herencia más arriba en la cadena.

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 completamente independientes de las reglas de herencia de LCA. Por ejemplo, una carpeta para borrar 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 proviene del método setInheritFrom(). Por lo tanto, el usuario 1 puede obtener acceso al elemento C porque este elemento hereda la LCA del elemento A.
• El acceso indirecto no viene del elemento C que contiene el elemento B. Por lo tanto, el usuario 2 no puede tener acceso al elemento C.

Figura 2: El 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 podrá buscar y se programará para la eliminación desde 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 borrado con el método setInheritFrom(), pero no tiene un contenedor configurado con setContainer(), o su jerarquía de contención no contiene elementos borrados, ese elemento y sus datos permanecerán 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.

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 mediante las referencias del contenedor.
• El elemento E no se puede buscar y ningún usuario puede buscarlo.