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.
Crea una LCA
La creación de una LCA es un proceso de dos pasos:
- Crea un
Principal
usando métodos estáticos ACL . - 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
.
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.
En la figura 1, se muestra cómo
El método setInheritFrom()
se usa para heredar las principales permitidas y las rechazadas indirectas.
![Dibujo de conexiones entre elementos](https://developers.google.cn/static/cloud-search/images/inherit-from-SDK.png?authuser=19&hl=es)
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 paraBOTH_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 comoCHILD_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 comoPARENT_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
. 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.
![Dibujo de conexiones entre elementos](https://developers.google.cn/static/cloud-search/images/doc-hierarchy-SDK.png?authuser=19&hl=es)
setInheritFrom()
en usoLa 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.
![Dibujo de conexiones entre elementos](https://developers.google.cn/static/cloud-search/images/doc-hierarchy-deletion-SDK.png?authuser=19&hl=es)
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.