El control de acceso en Google Cloud Search se basa en la Cuenta de Google del usuario. Cuando se indexa el contenido, todas las LCA de los elementos deben establecer un vínculo con los ID de usuarios o grupos de Google válidos (direcciones de correo electrónico).
En muchos casos, un repositorio no tiene conocimiento directo de las Cuentas de Google. En su lugar, los usuarios pueden estar representados por cuentas locales o utilizar el acceso federado con un proveedor de identidad y un ID, distintos de la dirección de correo electrónico del usuario, para identificar cada cuenta. Este ID se denomina el ID externo.
Las fuentes de identidad, que se crean con la Consola del administrador, ayudan a salvar la distancia entre los sistemas de identidad de la siguiente manera:
- La definición de un campo de usuario personalizado para almacenar ID externos. Este campo se utiliza para establecer un vínculo de ID externos con una Cuenta de Google.
- Define un espacio de nombres para grupos de seguridad. administrados por un repositorio proveedor de identidad.
Utiliza fuentes de identidad cuando ocurra cualquiera de las dos situaciones que se indican a continuación:
- El repositorio no tiene conocimiento de la dirección de correo electrónico principal de al usuario en Google Workspace o en el directorio de Google Cloud.
- El repositorio define grupos para el control de acceso que no corresponden a grupos basados en correos electrónicos en Google Workspace.
Las fuentes de identidad mejoran la eficiencia de la indexación; para ello, se separa la indexación de la asignación de identidad. Esta separación te permite aplazar la búsqueda del usuario cuando crees LCA e indexes elementos.
Implementación de ejemplo
La Figura 1 muestra una implementación de ejemplo en la que una empresa utiliza tanto los repositorios locales como los repositorios en la nube. Cada repositorio utiliza un tipo diferente de ID externo para referirse a los usuarios.
![Implementación de ejemplo](https://developers-dot-devsite-v2-prod.appspot.com/static/cloud-search/images/identity-arch.png?authuser=0000&hl=es)
El repositorio 1 identifica al usuario con la dirección de correo electrónico declarada con SAML Porque el repositorio 1 tiene conocimiento de la dirección de correo electrónico principal del usuario en Google Workspace o Cloud Directory, no se necesita una fuente de identidad.
El repositorio 2 se integra directamente en un directorio local y
identifica al usuario mediante su atributo sAMAccountName
. Debido a que el repositorio 2
usa un atributo sAMAccountName
como ID externo, se crea una
según tus necesidades.
Crear una fuente de identidad
Si necesitas una fuente de identidad, consulta Mapea identidades de usuario en Cloud Search.
Debes crear una fuente de identidad antes de crear un conector de contenido porque necesitarás el ID de la fuente de identidad para crear LCA e indexar datos. Como se mencionó anteriormente, la creación de una fuente de identidad también crea una propiedad del usuario personalizada en Cloud Directory. Utiliza esta propiedad para registrar el ID externo de cada usuario en el repositorio. Se asigna un nombre a la propiedad con el
convención IDENTITY_SOURCE_ID_identity
.
En la siguiente tabla, se muestran dos fuentes de identidad, una para contener los nombres de la cuentas SAM (sAMAccountName) como ID externos y otra para contener los ID de usuarios (uid) como ID externos.
Fuente de identidad | propiedad del usuario | ID externo |
---|---|---|
id1 | id1_identity | sAMAccountName |
id2 | id2_identity | uid |
Crea una fuente de identidad para cada ID externo posible que se utilice para hacer referencia a un usuario en la empresa.
En la siguiente tabla, se muestra cómo un usuario con una Cuenta de Google y dos ID externos (id1_identity y id2_identity) y sus valores aparecen en Cloud Directory:
usuario | correo electrónico | id1_identity | id2_identity |
---|---|---|---|
Ann | ann@example.com | example\ann | 1001 |
Puedes hacer referencia al mismo usuario mediante tres ID diferentes, (correo electrónico de Google, sAMAccountName y uid) cuando se formulen las LCA para la indexación.
Escribe LCA de usuario
Usa el getUserPrincpal() getGroupPrincipal() método para crear principales con un ID externo proporcionado.
En el siguiente ejemplo, se demuestra cómo obtener permisos de archivos. Estos permisos incluyen el nombre de cada usuario que tiene acceso al archivo.
En el siguiente fragmento de código, se muestra cómo crear principales que son propietarios
con el ID externo (externalUserName
) almacenado en los atributos.
Por último, en el siguiente fragmento de código, se muestra cómo crear principales que son lectores del archivo.
Una vez que tengas una lista de lectores y propietarios, puedes crear la LCA:
La API de REST subyacente usa el patrón
identitysources/IDENTITY_SOURCE_ID/users/EXTERNAL_ID
para el ID cuando se crean principales. Volviendo a las tablas anteriores,
si creas una LCA con el id1_identity
de Ann (SAMAccountName), el ID
resolver para:
identitysources/id1_identity/users/example/ann
Este ID completo se denomina ID intermedio del usuario porque proporciona un puente entre el ID externo y los ID de Google almacenados en Cloud Directory.
Para obtener más información sobre el modelado de las LCA utilizadas para un repositorio, consulta LCA.
Mapea grupos
Las fuentes de identidad también actúan como un espacio de nombres para los grupos que se utilizan en las LCA. Puedes usar esta característica de espacio de nombres para crear y mapear grupos utilizados solo con fines de seguridad o que son locales en un repositorio.
Utiliza la API de Cloud Identity Groups para crear un grupo y administrar las membresías. Para asociar el grupo con una fuente de identidad, utiliza el nombre del recurso de la fuente de identidad como espacio de nombres del grupo.
En el siguiente fragmento de código, se muestra cómo crear un grupo con el uso de la API de Cloud Identity Groups:
Crear una LCA grupal
Para crear una LCA grupal, usa el getGroupPrincipal() para crear una principal grupal con un ID externo proporcionado. Luego, compila la LCA con la Acl.Builder clase de la siguiente manera:
Conectores de identidad
Si bien puedes usar ID externos que no sean de Google para indexar elementos y crear LCA, los usuarios no pueden ver los elementos en una búsqueda hasta que los ID externos establezcan un vínculo con un ID de Google en Cloud Directory. Existen tres maneras de garantizar que Cloud Directory conozca tanto el ID de Google como los ID externos de un usuario:
- Actualiza manualmente cada perfil de usuario individual a través de la Consola del administrador. Este proceso solo se recomienda para probar y realizar prototipados con el uso de algunos perfiles de usuario.
- Mapea los ID externos a los ID de Google ID con la API de Directory. Este proceso se recomienda para aquellos que no pueden usar el SDK de Identity Connector.
- Crea un conector de identidad con el SDK de Identity Connector. Este SDK simplifica el uso de la API de Directory para asignar IDs.
Los conectores de identidad son programas utilizados para mapear ID externos de identidades empresariales (usuarios y grupos) a identidades internas de Google que Google Cloud Search utiliza. Si tienes que crear una fuente de identidad, debes crear un conector de identidad.
Google Cloud Directory Sync (GCDS) es un ejemplo de un conector de identidad. Este conector de identidad mapea información de usuarios y grupos de Active Directory de Microsoft a Cloud Directory junto con los atributos de usuario que pueden representar su identidad en otros sistemas.
Sincronizar identidades con la API de REST
Usa el método update
para sincronizar identidades con la API de REST.
Reasigna identidades
Después de volver a asignar la identidad de un elemento a otra identidad, debes volver a indexar los elementos. para que se afiance la nueva identidad. Por ejemplo:
- Si intentas quitar una asignación de un usuario o reasignarla a otro, el la asignación original se conserva hasta que vuelves a indexarla.
- Si borras un grupo asignado que está presente en una LCA de elementos y, luego, creas una
grupo nuevo con el mismo
groupKey
, el grupo nuevo no proporcionará acceso al elemento hasta que se vuelva a indexar.