Implémentation de l’application (applications Web + SSO)

Implémentation de l’application dans un scénario d’application Web standard

Passons en revue l’implémentation de notre application Web standard. Nous avons utilisé ASP.NET Core pour cette implémentation; vous trouverez le code dans ce dépôt GitHub.

L’exemple contient une application qui utilise l’intégration Active Directory pour authentifier les employés de l’entreprise, ainsi qu’une connexion de base de données Auth0 pour les sous-traitants externes. L’autorisation est implémentée à l’aide de Rules et de claims, comme nous le verrons en détail dans cette section.

​

Connexion utilisateur

Auth0 fournit le widget Lock, qui sert de composant de connexion pour votre application. Vous n’avez donc pas à implémenter votre propre écran de connexion. Le widget Lock s’intègre de façon transparente à toutes les connexions que vous configurez dans votre Auth0 Dashboard, qu’il s’agisse de connexions de base de données, sociales ou d’entreprise.

Il existe plusieurs façons d’implémenter un écran de connexion avec une application Web et Auth0 :

• Lock hébergé : utilisez une instance du widget Lock hébergée sur l’infrastructure d’Auth0.
• Lock intégré : intégrez le widget Lock dans une page Web de votre application. Vous disposez de certaines options de personnalisation pour le widget Lock lui-même et d’un contrôle total sur le reste du code HTML de la page.
• Interface utilisateur personnalisée : développez une page Web entièrement personnalisée pour l’écran de connexion. Le formulaire HTML personnalisé enverra les données à votre serveur qui, à son tour, authentifiera l’utilisateur à l’aide de l’Authentication API. Pour savoir quand utiliser une interface utilisateur personnalisée, consultez Personnaliser les pages de Classic Login avec Lock ou le SDK.

​

Automatiser la détection du domaine d’origine (HRD)

Par défaut, Lock affiche toutes les connexions disponibles pour la connexion. Le choix du fournisseur d’identité approprié parmi plusieurs options s’appelle la détection du domaine d’origine (HRD). Dans notre cas, les options sont soit l’authentification avec Active Directory (pour les employés de l’entreprise), soit l’utilisation d’un courriel et d’un mot de passe pour notre connexion de base de données (consultants externes).

Vous pouvez toutefois vouloir éviter cette première étape, où l’utilisateur doit choisir le fournisseur d’identité (IdP), et laisser plutôt le système l’identifier au lieu de le demander chaque fois. Lock vous offre les options suivantes :

• Identifier l’IdP par programmation : lorsque vous lancez une transaction d’authentification avec Auth0, vous pouvez envoyer, au besoin, un paramètre connection. Cette valeur correspond directement à toute connexion définie dans votre tableau de bord. Lorsque vous utilisez la version hébergée de Lock en appelant le point de terminaison /authorize, vous pouvez transmettre un paramètre de chaîne de requête connection contenant le nom de la connexion. Sinon, si vous utilisez Lock intégré, c’est aussi simple que d’écrire auth0.show({connections: ['{yourConnection}']});.

  • Il existe plusieurs façons pratiques d’obtenir la valeur connection. L’une d’elles consiste à utiliser des URL personnalisées : par exemple, les employés de l’entreprise utiliseront https://internal.yoursite.com, tandis que les consultants externes utiliseront https://external.yoursite.com.

• Utiliser des domaines de courriel : Lock peut utiliser les domaines de courriel pour acheminer les demandes d’authentification. Les connexions d’entreprise dans Auth0 peuvent être associées à des domains. Si une connexion est configurée ainsi, la zone de texte du mot de passe est automatiquement désactivée lorsqu’on saisit un courriel ayant un domaine associé. Notez que vous pouvez associer plusieurs domaines à une seule connexion.

Pour en savoir plus sur ce sujet, consultez Sélectionner parmi plusieurs options de connexion.

​

Gestion des sessions

Lorsqu’il est question de gérer les sessions, il faut généralement prendre en compte trois couches de session :

• Session d’application : la première est la session à l’intérieur de l’application. Même si votre application utilise Auth0 pour authentifier les utilisateurs, vous devez tout de même garder la trace du fait que l’utilisateur s’est connecté à votre application. Dans une application web classique, cela se fait en stockant des informations dans un cookie.
• Session Auth0 : ensuite, Auth0 conserve aussi une session et stocke les informations de l’utilisateur dans un cookie. La prochaine fois qu’un utilisateur est redirigé vers l’écran Auth0 Lock, ses informations sont conservées.
• Session du fournisseur d’identité : la dernière couche est celle du fournisseur d’identité, par exemple Facebook ou Google. Lorsque vous permettez aux utilisateurs de se connecter avec l’un de ces fournisseurs et qu’ils y sont déjà connectés, ils n’auront pas à se reconnecter. Ils pourraient simplement devoir accorder les autorisations nécessaires pour partager leurs informations avec Auth0, puis avec votre application.

Lors du développement d’une application web, vous devez donc garder la trace du fait que l’utilisateur s’est connecté à votre application web. Vous pouvez le faire au moyen d’une session basée sur des cookies afin de suivre l’état de connexion de l’utilisateur et de stocker les informations ou jetons qui lui sont associés.

​

Comment puis-je contrôler la durée de la session locale de l’application de l’utilisateur ? Puis-je la piloter depuis Auth0 ?

L’application web contrôle entièrement la session locale de l’utilisateur. La façon de procéder dépend généralement de la pile web utilisée (par exemple, ASP.NET). Dans tous les cas, les différentes approches s’appuient ultimement sur un ou plusieurs cookies pour contrôler la session. Le développeur peut choisir d’utiliser la date d’expiration du JWT ID Token renvoyé par Auth0 pour contrôler la durée de sa session, ou de l’ignorer complètement. Certains développeurs stockent l’ID Token lui-même dans l’état de session et mettent fin à la session de l’utilisateur lorsqu’il expire.

La raison d’utiliser l’expiration du jeton pour déterminer celle de la session locale est qu’elle vous permet de contrôler de manière centralisée la durée de la session d’un utilisateur depuis l’Auth0 Dashboard.

Le flux de connexion est le suivant :

1. Lancer le flux d’authentification OIDC : le navigateur de l’utilisateur envoie une requête à Auth0 pour lancer le flux OIDC.
2. Définir le cookie SSO : Auth0 définit un cookie pour stocker les informations de l’utilisateur.
3. Échanger le code et renvoyer l’ID Token : Auth0 renvoie une requête au serveur web avec le code. Le serveur web échange le code contre un ID Token.
4. Définir le cookie d’authentification et envoyer la réponse : le serveur web renvoie une réponse au navigateur et définit le cookie d’authentification de l’application pour stocker les informations de session de l’utilisateur.
5. Le cookie d’authentification est envoyé avec chaque requête suivante : le cookie d’authentification de l’application est envoyé avec chaque requête suivante comme preuve que l’utilisateur est authentifié.

​

En quoi la session SSO d’Auth0 a-t-elle une incidence sur la session de l’application ?

Auth0 gère sa propre session d’authentification unique. Les applications peuvent choisir de tenir compte de cette session SSO ou de l’ignorer lorsqu’il s’agit de maintenir leur propre session locale. Le widget Lock offre même une fonctionnalité spéciale qui lui permet de détecter l’existence d’une session SSO Auth0 et de demander à l’utilisateur s’il souhaite se reconnecter avec ce même compte.

Si c’est le cas, il est connecté sans avoir à saisir de nouveau ses identifiants auprès du fournisseur d’identité réel. Même si l’utilisateur ne s’est pas authentifié de nouveau, l’application exécute quand même un flux d’authentification avec Auth0 et obtient un nouvel ID Token, qui peut ensuite servir à gérer la nouvelle session locale de l’application.

Voir l’implémentation dans ASP.NET Core.

​

Déconnexion de l’utilisateur

Lorsque vous déconnectez l’utilisateur, vous devez de nouveau tenir compte des trois couches de session dont nous avons parlé plus tôt :

• Session d’application : vous devez déconnecter l’utilisateur de votre application Web en supprimant sa session.
• Session Auth0 : vous devez déconnecter l’utilisateur d’Auth0. Pour ce faire, redirigez l’utilisateur vers https://{yourDomain}/v2/logout. La redirection de l’utilisateur vers cette URL efface tous les témoins d’authentification unique définis par Auth0 pour l’utilisateur.
• Session du fournisseur d’identité : bien que ce ne soit pas une pratique courante, vous pouvez forcer l’utilisateur à se déconnecter du fournisseur d’identité utilisé, par exemple Facebook ou Google. Pour ce faire, ajoutez le paramètre de chaîne de requête federated à l’URL de déconnexion : https://{yourDomain}/v2/logout?federated.

Pour rediriger un utilisateur après la déconnexion, ajoutez un paramètre de chaîne de requête returnTo dont la valeur est l’URL cible : https://{yourDomain}/v2/logout?returnTo=http://www.example.com. Notez que vous devez ajouter l’URL returnTo à Allowed Logout URLs. Pour en savoir plus sur l’implémentation, consultez : Logout.

Le flux de déconnexion (sans inclure la déconnexion fédérée) est le suivant :

1. Initier le flux de déconnexion : le flux de déconnexion est lancé à partir du navigateur, par exemple lorsque l’utilisateur clique sur un lien Logout. Une requête est envoyée au serveur Web.
2. Effacer la session locale de l’utilisateur : la session ou le témoin d’application de l’utilisateur est effacé.
3. Rediriger le navigateur vers la déconnexion Auth0 : le navigateur de l’utilisateur est redirigé vers l’URL de déconnexion Auth0.
4. Effacer le cookie SSO : Auth0 efface le cookie SSO de l’utilisateur.
5. Rediriger vers l’URL après la déconnexion : Auth0 renvoie une réponse de redirection et redirige le navigateur de l’utilisateur vers le paramètre de chaîne de requête returnTo.

Consultez l’implémentation dans ASP.NET Core.

​

Contrôle d’accès

L’autorisation désigne le processus qui consiste à déterminer quelles actions un utilisateur peut effectuer dans votre application.

Vous pouvez soit implémenter l’autorisation directement dans votre application, indépendamment d’Auth0, soit utiliser l’une des méthodes offertes pour récupérer les niveaux d’autorisation de l’utilisateur, les inclure comme claims d’autorisation dans le ID Token et valider ces claims d’autorisation dans votre application, une fois le jeton récupéré, afin de contrôler l’accès.

Il existe plusieurs façons de récupérer et de définir les revendications d’autorisation de l’utilisateur lorsque vous utilisez Auth0 :

• En configurant et en utilisant l’Authorization Extension d’Auth0.
• En utilisant des groupes Active Directory. Ils peuvent être utilisés avec l’Authorization Extension en faisant correspondre des groupes Active Directory aux groupes que vous définissez à l’aide de l’Authorization Extension.
• En ajoutant des métadonnées au profil de l’utilisateur à l’aide de Rules.
• En appelant des services externes depuis une Rule.

Puisque, dans notre cas, l’entreprise a déjà mis en place Active Directory, nous appliquerons le contrôle d’accès à l’aide de l’Authorization Extension en combinaison avec des groupes Active Directory.

Authorization Extension

À ce stade, l’Authorization Extension est principalement conçue pour appliquer une autorisation à gros grain, par exemple pour contrôler l’accès à une application en fonction de l’appartenance d’un utilisateur à un groupe. Elle n’est pas nécessairement conçue pour gérer un contrôle d’accès fin (par exemple, déterminer si un utilisateur peut effectuer une action précise dans l’application), même si c’est ainsi que nous l’utilisons dans ce cas.

Tous les utilisateurs seront implicitement des utilisateurs réguliers, mais les administrateurs des feuilles de temps seront affectés au groupe Admin, ce qui leur permettra d’approuver les feuilles de temps. L’Authorization Extension permet d’associer des groupes à des appartenances à des groupes existantes.

Tous les administrateurs des feuilles de temps seront affectés au groupe Timesheet Administrators dans Active Directory, qui sera automatiquement associé au groupe Admin dans l’application Timesheet.

Lorsque vous installez l’Authorization Extension, elle crée une Rule en arrière-plan, qui effectue les opérations suivantes :

1. Déterminer l’appartenance de l’utilisateur aux groupes.
2. Stocker les informations sur l’appartenance de l’utilisateur aux groupes dans app_metadata.
3. Ajouter l’appartenance de l’utilisateur aux groupes au jeton sortant.
4. Vérifier que l’utilisateur a obtenu l’accès à l’application actuelle.

​

Installer l’Authorization Extension

Pour installer l’Authorization Extension, accédez à la vue Extensions de votre Auth0 Dashboard, puis sélectionnez et installez l’extension Auth0 Authorization.

Une fois installée, l’application apparaîtra dans la section Installed Extensions.

Lorsque vous cliquez sur le lien pour ouvrir l’extension pour la première fois, vous serez invité à autoriser l’extension à accéder à votre compte Auth0. Si vous acceptez, vous serez redirigé vers l’Authorization Dashboard.

Une fois dans l’Authorization Dashboard, accédez à Groups dans le menu de navigation, puis créez un nouveau groupe nommé Admin.

Après avoir ajouté le groupe, vous pouvez cliquer sur ce nouveau groupe pour accéder à la section de gestion du groupe. Allez à l’onglet Group Mappings et ajoutez un nouveau mappage de groupe qui associera tous les utilisateurs Active Directory des groupes Timesheet Admins au groupe Admin que vous venez de créer.

Une fois que vous avez cliqué sur Save, le nouveau mappage apparaît dans la liste.

Une fois le mappage configuré, vous n’avez qu’à gérer l’appartenance au groupe Timesheet Admins dans Active Directory, et ces utilisateurs seront automatiquement associés au groupe Admin dans votre application.

Pour en savoir plus, consultez la documentation de l’Authorization Extension.

​

Appliquez les autorisations dans votre application

Lorsque vous avez installé l’Authorization Extension, celle-ci a également créé une Rule Auth0 qui ajoute une revendication authorization contenant tous les paramètres liés à l’autorisation pour un utilisateur donné. Les groupes d’un utilisateur sont ajoutés comme sous-revendication de la revendication authorization, appelée groups, et tous les groupes auxquels cet utilisateur appartient sont ajoutés à cette revendication sous forme de tableau. Voici un exemple de ce à quoi peut ressembler le payload JSON d’un ID Token avec les groupes indiqués :

{
  "sub": "1234567890",
  "name": "John Doe",
  "authorization": {
    "groups": ["Admin"]
  }
}

Dans votre application, vous devrez donc décoder l’ID Token renvoyé lorsqu’un utilisateur est authentifié, puis extraire de la revendication authorization les groupes auxquels il appartient. Vous pourrez ensuite stocker ces groupes, ainsi que d’autres renseignements sur l’utilisateur, dans sa session, puis les interroger pour déterminer s’il dispose des autorisations nécessaires pour effectuer une action donnée en fonction de son appartenance à un groupe.

Consultez l’implémentation dans ASP.NET Core.