¿Puede Awingu utilizar un proveedor de identidades externo como Azure AD u Okta?

Como solución de puesto de trabajo unificado, Awingu cubre muchos ángulos. La autenticación es uno de ellos. Analicemos Awingu como una plataforma que permite la autenticación de inicio de sesión único en los sistemas legacy en lugar de Awingu como una plataforma de "espacio de trabajo".

Para empezar, hay que diferenciar entre

A. Autenticación en el lugar de trabajo de Awingu

B. Autenticación en servicios back-end (por ejemplo, un Desktop remoto, una aplicación de Windows legacy o un servidor de archivos)

Dos fases en el proceso de autentificación

A. Autenticación en Awingu

Awingu admite muchas técnicas de autenticación. La más utilizada hoy en día sigue siendo un clásico Nombre de usuario/contraseña procedimiento (1). Las credenciales se basan en Active Directory (o LDAP). Awingu también admite muchas formas de añadir la autenticación multifactorial (MFA). Awingu soporta tanto Time-based password (TOTP) o Counter-based password (HOTP) como 2^nd (lo que significa que puede utilizar aplicaciones móviles nativas como Microsoft Authenticator y Google Authenticator para generar un token seguro). Junto al sabor incorporado, Awingu es compatible con muchas otras plataformas comerciales.

Con el aumento de los servicios SaaS, también llegó el aumento de los proveedores de identidad externos (IdP). Me vienen a la mente servicios como Okta y Microsoft Azure AD. Su propuesta inicial se centraba en la agregación de los inicios de sesión de los servicios SaaS para facilitar la vida a los usuarios finales y a los administradores. A partir de ahí, han evolucionado y se han expandido a otros dominios. Awingu puede aprovechar estos IDP externos en modo de "preautenticación" (a partir de Awingu 4.2) o de "inicio de sesión único completo" (a partir de Awingu 4.3). Awingu soporta los protocolos SAML y OpenID Connect (una evolución de OAuth) para establecer una confianza con el IdP elegido. Estos estándares son soportados por la gran mayoría de los proveedores.

(2) Preautenticación significa que el usuario debe autenticarse primero en el IdP y luego completar el proceso de inicio de sesión en Awingu. El IdP es central y tiene una visión completa de toda la actividad del usuario. También se pueden aprovechar los servicios adicionales del IdP (por ejemplo, MFA, geo-fencing, acceso restringido en el tiempo, ...).

(3) SSO completo significa que el usuario sólo tiene que autenticarse en el IdP. No es necesario ningún otro proceso de inicio de sesión. También en este escenario, se pueden aprovechar los servicios de IdP.

En algunos casos, se utilizan plataformas basadas en tarjetas inteligentes. No son infrecuentes, por ejemplo, en el sector sanitario y financiero. Awingu también puede soportar algunos de estos escenarios. Algunos de los proveedores de plataformas son compatibles con SAML o OpenID Connect, mientras que otros -como Imprivata, por ejemplo- también ofrecen "bóveda" de credenciales.

B. Autenticación en aplicaciones y servidores de archivos

Bien, ya te has autentificado en el espacio de trabajo de Awingu. Ahora querrás acceder a aquellas aplicaciones, escritorios y servidores de archivos que estés autorizado a utilizar.

Para los servicios, Awingu admite lo siguiente:

• Aplicaciones y escritorios Windows basados en RDP. Aquí, Awingu apoyará
  • autenticación clásica basada en nombre de usuario y contraseña
  • un modelo de autenticación propietario basado en certificados PKI (a partir de Awingu 4.3). Esto es necesario cuando se utiliza el "SSO completo" a un IdP externo. En este escenario, Awingu no tiene las credenciales reales de nombre de usuario y contraseña para trabajar. Awingu "confiará" en el IdP cuando autentifique a un usuario específico para que sea realmente dicho usuario (nota: no hay suplantación del usuario).
• Servicios SaaS: Hay dos maneras de ofrecer a los usuarios finales una experiencia SSO a los servicios SaaS dentro de Awingu:
  • Utiliza Awingu como IdP. Awingu tiene un conjunto predefinido de conectores con servicios SaaS populares como Office 365, Google Apps y Salesforce. Al utilizar estos conectores, Awingu se utiliza como un IdP externo.
  • Utilizar un IdP externo, en combinación con las opciones de autenticación de Awingu (2) y (3). En este caso, los servicios SaaS se conectan al IdP externo elegido, y los enlaces a los servicios SaaS se publican en Awingu sin más. Una vez que el usuario final inicia sesión en el espacio de trabajo de Awingu, se autentifica ante el IdP y, por tanto, para sus servicios SaaS. Este escenario permite añadir muchos más servicios SaaS en comparación con Awingu como IdP.
• Intranet o aplicaciones web internas: Awingu soporta la 'Autenticación Básica' aquí. Atención, requiere una autenticación basada en nombre de usuario/contraseña, por lo que no funcionará junto con (3)
• Servidores de archivos: Awingu admite CIFS y WebDAV (autenticación básica) para conectarse a servidores de archivos ("unidades SMB"). Este último no es compatible con (3)

Resumen: opción de autenticación primaria con Awingu

En el resumen anterior, hemos hecho abstracción de la autenticación basada en la red. En algunos escenarios puede ser un requisito adicional. En este nivel, Awingu también puede soportar la autenticación basada en Kerberos y NTLM.