En este artículo se ofrece más información sobre cómo usar identidades externas con Identity-Aware Proxy (IAP) en lugar de cuentas de Google.
Información general
IAP controla el acceso a tus aplicaciones y recursos. Aprovecha la identidad del usuario y el contexto de una solicitud para determinar si se le debe permitir el acceso. IAP es uno de los componentes de Chrome Enterprise Premium, una solución de seguridad empresarial que permite a los empleados trabajar a través de redes que no sean de confianza sin necesidad de usar una VPN.
De forma predeterminada, IAP usa identidades de Google e IAM. Si utilizas Identity Platform, puedes autenticar a los usuarios con una amplia gama de proveedores de identidades externos, como los siguientes:
- Correo electrónico y contraseña
- OAuth (Google, Facebook, Twitter, GitHub, Microsoft, etc.)
- SAML
- OIDC
- Número de teléfono
- Personalizado
- Anónimo
Esto resulta útil si tu aplicación ya usa un sistema de autenticación externo y no es práctico migrar a tus usuarios a cuentas de Google.
Arquitectura multicliente
La propiedad múltiple de Identity Platform se diseñó originalmente para escenarios B2B, en los que una empresa vende un servicio a otras empresas. En estos casos, es habitual que los desarrolladores quieran segregar a los usuarios en grupos aislados. Estos silos se denominan inquilinos.
Veamos el siguiente diagrama de relaciones ficticio:
En este ejemplo, Acme es un fabricante de automóviles (el agente) que usa Identity Platform para ofrecer un servicio a los concesionarios (los clientes). A su vez, estos concesionarios prestan servicios a sus clientes, empleados y contratistas. Aunque el fabricante es el propietario del servicio, cada concesionario puede usar su propio conjunto de proveedores de identidad para la autenticación. Las sesiones de usuario y los datos se acotan por inquilino, por lo que, si un usuario tiene relaciones con varios concesionarios, cada una se gestiona de forma independiente.
En función de tu caso práctico, hay varias formas de estructurar tu jerarquía de inquilinos.
No hay clientes
Solo necesitas el multitenancy si quieres aislar recursos. No todas las aplicaciones tienen este requisito. Por ejemplo, si tienes una sola aplicación de App Engine y quieres bloquear el acceso a todos los usuarios que no estén en tu red, no necesitas el multitenancy. De forma predeterminada, Identity Platform almacena y autentica a los usuarios por proyecto, por lo que no es necesario realizar ninguna configuración adicional en este caso.
Otro ejemplo es un conglomerado con varias filiales. Aunque cada filial tenga su propio sistema de autenticación gestionado (con OIDC o SAML), es posible que todos los empleados compartan las mismas ventajas generales, como la asistencia sanitaria, las vacaciones y la nómina. En este caso, basta con autenticarse a nivel de proyecto.
Un arrendatario por recurso
De forma predeterminada, los tokens de Identity Platform que no son de un arrendatario son válidos a nivel de proyecto. En teoría, esto significa que un usuario podría autenticarse con un recurso de IAP y, después, usar el token para acceder a otro servicio del mismo proyecto. Esto supone un riesgo para la seguridad.
Para evitar fugas de tokens, aísla cada compra en la aplicación asignándole su propio cliente. Los tokens acuñados en un contexto específico de un arrendatario solo son válidos para ese arrendatario. Si el usuario intenta acceder a otro recurso de IAP que usa un inquilino diferente, se le pedirá que se autentique de nuevo.
Varios arrendatarios por recurso
Un solo recurso de IAP puede tener varios arrendatarios asociados.
Cuando un usuario accede al recurso, tiene varias opciones para determinar qué cliente usar. Por ejemplo, puede pedir al usuario que introduzca su correo primero y, a continuación, buscar de forma programática un inquilino que coincida con el dominio del correo. También puedes mostrar una interfaz de usuario que incluya todos los arrendatarios válidos y pedir al usuario que elija uno.
Los usuarios pueden pertenecer a varios arrendatarios con diferentes niveles de acceso. Aunque no puedes usar IAM para gestionar el control de acceso con identidades externas, el token web JSON generado por IAP incluye las reclamaciones del token de ID de Identity Platform, y la aplicación puede filtrar el acceso en función de estas reclamaciones.
Un ejemplo de escenario de multitenencia 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 (el arrendatario) y, a continuación, se autentica con el proveedor que utilice su empresa con sus credenciales corporativas.