Asigna las LCA

Para garantizar que solo los usuarios con acceso a un elemento puedan verlo dentro de un resultado de la búsqueda, debes indexar los elementos con sus listas de control de acceso (LCA) del repositorio de Enterprise. Debes modelar las LCA de tu repositorio incluir esas LCA cuando indexas elementos en el repositorio. El conector de contenido SDK proporciona un conjunto amplio de métodos de LCA lo suficientemente potente para modelar las LCA de de la mayoría de los repositorios.

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

Crea una LCA

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

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

El resto de este documento abarca algunos conceptos que debes conocer 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 conector de contenido SDK te permite usar cualquier ID externo (ID que otorga a un usuario o grupo el acceso a los elementos del repositorio) de una dirección de correo electrónico, para indexar un elemento. Usa el getUserPrincipal() getGroupPrincpal() para crear principales que contengan IDs externos. Hay varias otras métodos estáticos en la ACL clase usada para crear Principal.

Nota: Los usuarios no verán los elementos en los resultados de la búsqueda hasta que tengan un ID externo. esté sincronizado 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 identidad, debes vuelve a indexar los elementos para que se aplique la nueva identidad. Para obtener más información, consulta a Reasignación de identidades.

Herencia de LCA

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

Configura la herencia

Cada elemento puede tener principales permitidos directos y también principales denegados directos, especificada mediante 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.

Un elemento también puede heredar principales permitidas indirectas y principales denegados indirectos con el 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 setInheritFrom() debes establecer el tipo de herencia con el setInheritanceType() . Para obtener información sobre los tipos de herencia, consulta Configura el tipo de herencia.

En la figura 1, se muestra cómo El método setInheritFrom() se usa para heredar las principales permitidas y las rechazadas indirectas.

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 setInheritFrom() debes establecer el tipo de herencia con el setInheritanceType() . El tipo de herencia determina cómo se Se combina con la LCA de su superior. La 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 el elemento secundario. la LCA del elemento principal tendrá prioridad sobre la LCA del elemento superior cuando se 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: Configura el tipo de herencia como PARENT_OVERRIDE para forzar la la LCA del elemento superior tenga prioridad sobre la LCA del elemento secundario cuando 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 la LCA de una cadena comienza con la evaluación de un elemento secundario con sus elementos superiores y puede progresar hasta llegar a la raíz superior.

Por ejemplo, si el elemento secundario tiene el tipo de herencia CHILD_OVERRIDE y el usuario tiene acceso al elemento secundario, por lo tanto, Drive no necesita evaluar al elemento superior. Sin embargo, si el niño tiene PARENT_OVERRIDE o BOTH_PERMIT, Drive continúa para evaluar la herencia más adelante en la cadena.

Contención y eliminación de elementos

Cuando indexas un elemento, puedes etiquetarlo como contenedor con el setContainer() de la IndexingItemBuilder clase. La relación entre el contenedor y su contenido establece la estructura de los elementos y garantiza que estos se borren correctamente. 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 de 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: Método setInheritFrom() en uso

La separación de la herencia de LCA de la jerarquía de contención te permite modelar de 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 haya especificado el elemento borrado con el Método setInheritFrom() no se puede buscar.

Si un recurso tiene un elemento borrado con el setInheritFrom() de destino, pero no tiene un conjunto de contenedores que use 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.

Figura 3: Borra una herencia de elemento y 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 elementos subordinados de setInheritFrom() referencia perderán 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.