Awingu comme plateforme d'authentification sécurisée pour vos services legacy

En tant que solution de travail unifié, Awingu couvre de nombreux aspects. L'authentification est l'un d'entre eux. Dans ce billet de blog, nous allons nous concentrer sur l'Awingu en tant que plateforme permettant l'authentification par signature unique aux systèmes legacy plutôt que sur l'Awingu en tant que plateforme d'espace de travail.

Pour commencer, nous devons faire la différence entre

A. S'authentifier sur le lieu de travail d'Awingu

B. Authentification dans les services dorsaux (par exemple, un Desktop distant, une application Windows legacy ou un serveur de fichiers).

Deux phases dans le processus d'authentification

A. Authentification dans Awingu

Awingu supporte de nombreuses techniques d'authentification. La plus utilisée aujourd'hui reste un classique nom d'utilisateur/mot de passe" login procédure (1). Les informations d'identification sont basées sur Active Directory (ou LDAP). Awingu supportera également de nombreuses façons d'ajouter l'authentification multifactorielle (MFA). Construit, Awingu supporte à la fois Time-based password (TOTP) ou Counter-based password (HOTP) en tant que 2^et (ce qui signifie que vous pouvez utiliser des applications mobiles natives telles que Microsoft Authenticator et Google Authenticator pour générer un jeton sécurisé). Ensuite, la saveur intégrée, Awingu supporte de nombreuses autres plateformes commerciales.

L'essor des services SaaS s'est accompagné de celui des fournisseurs d'identité externes (IdP). Des services tels que Okta et Microsoft Azure AD viennent à l'esprit. Leur proposition initiale était axée sur l'agrégation des logins pour les services SaaS afin de faciliter la vie des utilisateurs finaux et des administrateurs. À partir de là, ils ont évolué et se sont étendus à d'autres domaines. Awingu peut tirer parti de ces IDP externes en mode "pré-authentification" (à partir de Awingu 4.2) ou "signature unique complète" (à partir de Awingu 4.3). Awingu supporte les protocoles SAML et OpenID Connect (une évolution de OAuth) pour établir une confiance avec l'IdP choisi. Ces standards sont supportés par la grande majorité des fournisseurs.

(2) Pré-authentification signifie que l'utilisateur doit d'abord s'authentifier auprès de l'IdP, puis compléter le processus de connexion dans Awingu. L'IdP est central et a un aperçu complet de toute l'activité de l'utilisateur. Des services supplémentaires de l'IdP (par exemple, MFA, geo-fencing, accès limité dans le temps, ...) peuvent également être utilisés.

(3) SSO complet signifie que l'utilisateur doit uniquement s'authentifier auprès de l'IdP. Aucun autre processus de connexion n'est nécessaire. Dans ce scénario également, les services IdP peuvent être exploités.

Dans certains cas, des plateformes basées sur des cartes à puce sont utilisées. Celles-ci ne sont pas rares, par exemple, dans les secteurs de la santé et de la finance. Awingu peut également prendre en charge certains de ces scénarios. Certains fournisseurs de plates-formes prennent en charge SAML ou OpenID Connect, d'autres - comme Imprivata par exemple - proposent également la mise en coffre des justificatifs.

B. Authentification dans les applications et les serveurs de fichiers

Ok, donc vous vous êtes authentifié dans l'espace de travail Awingu. Maintenant, vous voulez accéder aux applications, aux bureaux et aux serveurs de fichiers que vous êtes autorisé à utiliser.

Pour les services, Awingu prend en charge les éléments suivants :

• Applications et postes de travail Windows basés sur le protocole RDP. Ici, Awingu va soutenir
  • authentification classique par nom d'utilisateur et mot de passe
  • un modèle d'authentification propriétaire basé sur un certificat PKI (à partir d'Awingu 4.3). Ceci est nécessaire lors de l'utilisation de "full SSO" à un IdP externe. Dans ce scénario, Awingu n'a pas le nom d'utilisateur et le mot de passe pour travailler avec. Awingu fera 'confiance' à l'IdP quand il authentifie un utilisateur spécifique pour être réellement le dit utilisateur (note : il n'y a pas d'usurpation d'identité de l'utilisateur).
• Services SaaS: Il y a 2 façons de donner aux utilisateurs finaux une expérience SSO aux services SaaS dans Awingu :
  • Utilisez Awingu comme IdP. Awingu a un ensemble prédéfini de connecteurs avec les services SaaS populaires tels que Office 365, Google Apps et Salesforce. En utilisant ces connecteurs, Awingu est utilisé comme un IdP externe.
  • Utiliser un IdP externe, en combinaison avec les options d'authentification Awingu (2) et (3). Dans ce cas, les services SaaS sont connectés à l'IdP externe choisi, et les liens vers les services SaaS sont publiés dans Awingu sans plus. Une fois que l'utilisateur final se connecte à l'espace de travail Awingu, il est authentifié auprès de l'IdP et donc pour ses services SaaS. Ce scénario permet d'ajouter beaucoup plus de services SaaS par rapport à Awingu comme IdP.
• Intranet ou applications web internes: Awingu prend en charge l'"authentification de base" ici. Attention, cela nécessite une authentification basée sur un nom d'utilisateur et un mot de passe, et ne fonctionnera donc pas en conjonction avec la fonction (3)
• Serveurs de fichiers: Awingu prend en charge CIFS et WebDAV (authentification de base) pour se connecter aux serveurs de fichiers ("lecteurs SMB"). Ce dernier n'est pas supporté en conjonction avec (3)

Aperçu sommaire : option d'authentification primaire avec Awingu

Dans l'aperçu ci-dessus, nous avons fait abstraction de l'authentification basée sur le réseau. Dans certains scénarios, cela pourrait être une exigence supplémentaire. À ce niveau, Awingu peut également supporter l'authentification basée sur Kerberos et NTLM.

Alors quoi... ?

L'aperçu ci-dessus montre que Awingu peut supporter un large éventail d'options d'authentification. Si votre entreprise a déjà choisi d'adopter un IdP externe tel que Okta, Identité Google Cloud ou Microsoft Azure AD pour les services SaaS, vous pouvez désormais enrichir facilement cette expérience avec des applications et des postes de travail legacy également.

Les utilisateurs finaux peuvent utiliser l'espace de travail d'Awingu comme point d'agrégation, mais ils peuvent aussi utiliser l'espace de travail de l'IdP et simplement cliquer sur le lien d'une application ou d'un poste de travail legacy publié (depuis Awingu 4.2, les "liens directs" sont supportés). Awingu fera tourner les applications/bureaux choisis dans un navigateur, en plein SSO. Sans problème.

Illustration : utiliser l'espace de travail d'Okta pour accéder aux applications Awingu et/ou publiées legacy

Lorsque vous utilisez déjà un IdP externe, vous pouvez également utiliser leurs services pour MFA, geofencing, accès limité dans le temps, etc. Ces services peuvent également être appliqués à Awingu.

Bon à savoir : Awingu est multi-tenant. Chaque locataire peut être configuré pour l'authentification de manière différente.

A propos de l'auteur

Arnaud Marliere

Directeur général des ventes et du marketing

Linkedin Twitter Facebook Youtube Enveloppe