Asigna las LCA

Para garantizar que solo los usuarios con acceso a un elemento puedan verlo en los resultados de la búsqueda, indexa 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 indexes elementos. El SDK de Content Connector proporciona métodos para modelar las LCA de la mayoría de los repositorios.

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

Crea una LCA

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

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

En este documento, se abordan conceptos para modelar y crear LCA, como la herencia y la 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 del conector de contenido te permite usar un ID externo (un ID que otorga a un usuario o grupo acceso a los elementos del repositorio) en lugar de una dirección de correo electrónico para indexar un elemento. Usa el método getUserPrincipal o el método getGroupPrincipal para crear principales que contengan IDs externos. La clase ACL incluye varios otros métodos estáticos 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. Puedes usar un conector de identidad para sincronizar los IDs externos de usuarios o grupos con una dirección de correo electrónico de Google. Para obtener más información, consulta Crea un conector de identidad.

Después de reasignar la identidad de un elemento, debes volver a indexar los elementos para que la nueva identidad se aplique. 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 de las LCA combinadas del elemento y su cadena de herencia. Las reglas para 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 con acceso directo a un elemento. Un principal denegado directo es un usuario identificado en una LCA sin acceso a un elemento.

Un elemento también puede heredar principales permitidos indirectos y principales denegados indirectos con el método setInheritFrom. Un principal permitido indirecto tiene acceso indirecto a un elemento a través de la herencia de LCA. Un principal denegado indirecto no tiene acceso a través de la herencia.

Nota: Si configuras la herencia con el método setInheritFrom, también 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 usar el método setInheritFrom para heredar principales.

Figura 1: El método setInheritFrom.

En la figura 1, se representan estos 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 elemento B hereda la LCA del elemento A.

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

• El usuario 1 es un principal permitido indirecto del elemento B sin que se especifique de forma explícita. El acceso se hereda 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 establecer el tipo de herencia con el método setInheritanceType. El tipo de herencia determina cómo se combina una LCA secundaria con una LCA principal. El objeto Acl.InheritanceType implementa tres tipos:

• BOTH_PERMIT: Otorga acceso solo cuando lo permiten las LCA secundarias y principales.
• CHILD_OVERRIDE: La LCA secundaria tiene prioridad sobre la LCA principal en caso de conflicto. Un usuario puede acceder al hijo o hija incluso si la madre o el padre lo niega, o se le puede negar el acceso al hijo o hija incluso si la madre o el padre lo permite.
• PARENT_OVERRIDE: La LCA principal tiene prioridad sobre la LCA secundaria en caso de conflicto.

Cloud Search evalúa las cadenas de herencia de LCA de hoja a raíz. La evaluación comienza con el hijo o la hija y sus padres, y puede avanzar hasta el padre o la madre raíz.

Por ejemplo, si el hijo usa CHILD_OVERRIDE y el usuario tiene acceso, Cloud Search no necesita evaluar al elemento principal. Sin embargo, si el hijo usa PARENT_OVERRIDE o BOTH_PERMIT, Cloud Search continúa evaluando 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. Esta relación establece la jerarquía física y garantiza la eliminación adecuada. Cuando borras un contenedor, también se borran los elementos que contiene.

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

En la figura 2, se representan estos 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 estos controles.

• El acceso indirecto proviene del método setInheritFrom. El usuario 1 puede acceder al elemento C porque lo hereda del elemento A.
• El acceso indirecto no proviene de la contención. El usuario 2 no puede acceder al elemento C.

Figura 2: Es el método setInheritFrom en uso.

La separación de la herencia de la LCA de la contención te permite modelar muchas estructuras.

Cuando borras un elemento, sucede lo siguiente:

• Cualquier elemento que contenga el elemento borrado no se podrá buscar y se programará para su eliminación.
• Cualquier elemento que especifique el elemento borrado en setInheritFrom no se podrá buscar.

Si un recurso usa setInheritFrom para un elemento borrado, pero no tiene un contenedor establecido o su jerarquía no contiene elementos borrados, el elemento permanece en la fuente de datos. Deberás borrarlo.

En la figura 3, se muestra un ejemplo de eliminación de una jerarquía de elementos.

Figura 3: Eliminación de un elemento y herencia de la LCA.

En la figura 3, se representan estos 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 del elemento A.
• El elemento D nombra al elemento A como su contenedor.
• Los elementos A y E están a nivel raíz.

Las eliminaciones se propagan en cascada a través de las referencias del contenedor. Cuando borras el elemento A, sucede lo siguiente:

• Todos los descendientes de la referencia setInheritFrom pierden el acceso.
• Los usuarios ya no pueden acceder al elemento A.
• El elemento D se borra de forma implícita y se vuelve inaccesible.
• El elemento E no se borra, pero no se puede buscar ni acceder a él.