En este artículo, se proporciona información adicional sobre el uso de identidades externas con Identity-Aware Proxy (IAP) en lugar de Cuentas de Google.
Descripción general
IAP controla el acceso a tus aplicaciones de App Engine y a las VM de Compute Engine que se ejecutan en Google Cloud. Aprovecha la identidad del usuario y el contexto de una solicitud para determinar si se debe permitir el acceso a un usuario. IAP es un componente fundamental de BeyondCorp, un modelo de seguridad empresarial que permite a los empleados trabajar desde redes que no son de confianza sin usar una VPN.
De forma predeterminada, IAP usa las identidades de Google y IAM. Cuando aprovechas Identity Platform, puedes autenticar usuarios con una amplia variedad de proveedores de identidad externa, como los siguientes:
- Correo electrónico y contraseña
- OAuth (Google, Facebook, Twitter, GitHub, Microsoft, etcétera)
- SAML
- OIDC
- Número de teléfono
- Personalizados
- Anónimos
Esto es útil si tu aplicación ya utiliza un sistema de autenticación externo y migrar tus usuarios a Cuentas de Google no es práctico.
Multiusuario
Multiusuario de Identity Platform se diseñó originalmente para las situaciones B2B, en las que una empresa vende un servicio a otras. En estos casos, es común que los desarrolladores deseen segregar los usuarios en grupos aislados. Estos sistemas aislados se denominan instancias.
Considera el siguiente diagrama de relación ficticia:
En este ejemplo, Acme es un fabricante de automóviles (el agente) que utiliza Identity Platform para proporcionar un servicio a los concesionarios (las instancias). Estos concesionarios ofrecen servicios a sus clientes, empleados y contratistas. Si bien el fabricante es el propietario del servicio, cada concesionario podría usar su propio conjunto de proveedores de identidad para la autenticación. Las sesiones y los datos de los usuarios se determinan por instancia, por lo que si un usuario tiene relaciones con varios concesionarios, cada uno se maneja de forma independiente.
Según tu caso práctico, existen varias maneras de estructurar la jerarquía de tus instancias.
No hay instancias
Solo necesitas tener multiusuarios si debes aislar recursos. No todas las aplicaciones tienen este requisito. Por ejemplo, si tienes una sola aplicación de App Engine y deseas bloquear el acceso a todos los usuarios que no pertenecen a tu red, no es necesario utilizar multiusuarios. De forma predeterminada, Identity Platform almacena y autentica usuarios por proyecto, por lo que no se requiere ninguna configuración adicional en este caso.
Otro ejemplo es un conglomerado con varias filiales. Incluso si cada filial tiene su propio sistema de autenticación administrada (OIDC o SAML), todos los empleados pueden compartir los mismos beneficios de alto nivel, como atención médica, vacaciones y nómina. En este caso, la autenticación a nivel del proyecto es suficiente.
Una instancia por recurso
De forma predeterminada, los tokens de Identity Platform que no son de instancia son válidos a nivel del proyecto. Teóricamente, esto significa que un usuario puede autenticarse con un recurso de IAP y, luego, usar el token para acceder a otro servicio en el mismo proyecto. Este es un riesgo de seguridad.
Para evitar filtraciones de token, aísla cada IAP asignando a cada uno su propia instancia. Los tokens que se crean en un contexto específico de la instancia solo son válidos para ese usuario específico. Si el usuario intenta acceder a otro recurso de IAP que utiliza una instancia diferente, se le solicitará que realice la autenticación nuevamente.
Varias instancias por recurso
Un solo recurso de IAP puede tener varias instancias asociadas.
Cuando un usuario accede al recurso, tienes varias opciones para determinar qué instancia usar. Por ejemplo, puedes solicitarle al usuario que ingrese primero su correo electrónico y, luego, localice de manera programática una instancia que coincida con el dominio del correo electrónico. Como alternativa, puedes mostrar una IU que enumere todas las instancias válidas y solicitarle al usuario que elija uno.
Los usuarios pueden pertenecer a varias instancias con diferentes niveles de acceso. Aunque no puedes usar IAM para administrar el control de acceso con identidades externas, el token web JSON que genera IAP transporta las reclamaciones del token de ID de Identity Platform, y la aplicación puede filtrar el acceso en función de estas reclamaciones.
Un caso de ejemplo de varias instancias es una empresa de beneficios para empleados que tiene muchos clientes que comparten un único portal web. Cuando un usuario visita el portal, primero selecciona su empresa (la instancia) y, luego, se autentica con cualquier proveedor que su empleador utilice con sus credenciales corporativas.