Mise en œuvre de l’application (applications web + SSO)

mise en œuvre de l’application dans le scénario d’application web traditionnelle

Passons en revue la mise en œuvre de notre application web traditionnelle. Nous avons utilisé ASP.NET Core pour cette mise en œuvre, et vous trouverez le code dans ce dépôt GitHub.

L’exemple présente une application qui utilise une 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 mise en œuvre à l’aide de rules et de claims, comme nous le verrons en détail dans cette section.

​

Connexion utilisateur

Auth0 fournit un widget Lock qui sert de composant de connexion pour votre application, ce qui signifie que vous n’avez pas à créer votre propre écran de connexion. Le widget Lock s’intègre parfaitement à 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 différentes façons de mettre en place un écran de connexion avec une application web et Auth0 :

• Hosted Lock : utilisez une instance du widget Lock hébergée sur l’infrastructure d’Auth0.
• Embedded Lock : intégrez le widget Lock dans une page web de votre application. Vous disposez de quelques options de personnalisation pour le widget Lock lui-même et d’un contrôle total sur le reste du HTML de la page.
• Custom UI : développez une page web entièrement personnalisée pour l’écran de connexion. Le formulaire HTML personnalisé transmettra les données à votre serveur, qui authentifiera ensuite l’utilisateur à l’aide de l’Authentication API. Pour en savoir plus sur les cas où utiliser une Custom UI, consultez Customize Classic Login Pages with Lock or SDK.

​

Automatiser Home Realm Discovery (HRD)

Par défaut, Lock affiche toutes les connexions disponibles pour la connexion. Le fait de sélectionner les fournisseurs d’identité appropriés parmi plusieurs options s’appelle Home Realm Discovery (HRD). Dans notre cas, les options sont soit de s’authentifier avec Active Directory (pour les employés de l’entreprise), soit d’utiliser un courriel et un mot de passe pour notre connexion de base de données (sous-traitants externes).

Vous pourriez toutefois vouloir éviter cette première étape, où l’utilisateur doit choisir le fournisseur d’identité (IdP), et plutôt laisser 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 à n’importe quelle connexion définie dans votre Dashboard. 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 Embedded Lock, il suffit d’écrire auth0.show({connections: ['{yourConnection}']});.

  • Il existe plusieurs façons pratiques d’obtenir la valeur de 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 sous-traitants externes utiliseront https://external.yoursite.com.

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

Pour plus d’informations sur ce sujet, consultez Sélectionner parmi plusieurs options de connexion.

​

Gestion des sessions

Lorsqu’on parle de gestion des sessions, il y a généralement trois couches de sessions à prendre en compte :

• Application Session : la première est la session à l’intérieur de l’application. Même si votre application utilise Auth0 pour authentifier les utilisateurs, vous devrez tout de même garder 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.
• Auth0 session : ensuite, Auth0 conservera aussi une session et stockera les informations de l’utilisateur dans un cookie. La prochaine fois qu’un utilisateur sera redirigé vers l’écran Auth0 Lock, ses informations seront conservées.
• fournisseur d’identité session : 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 sont déjà connectés auprès de ce fournisseur, ils n’auront pas à se connecter de nouveau. Ils pourraient simplement devoir accorder les permissions nécessaires pour partager leurs informations avec Auth0 et, par conséquent, avec votre application.

Lorsque vous développez une application web, vous devez donc garder 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 savoir que l’utilisateur est connecté, et y stocker aussi toute information ou tout jeton lié à l’utilisateur.

​

Comment contrôler la durée de la session locale de l’utilisateur dans l’application ? Puis-je la gérer à partir d’Auth0 ?

L’application web contrôle entièrement la session locale de l’utilisateur. La façon de le faire dépend habituellement de la pile web utilisée (par exemple, ASP.NET). Quoi qu’il en soit, toutes les approches utilisent ultimement un ou plusieurs cookies pour contrôler la session. Le développeur peut choisir d’utiliser l’expiration du JWT ID Token retourné par Auth0 pour contrôler la durée de sa session, ou de l’ignorer complètement. Certains développeurs stockent le 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 donne un contrôle centralisé sur la durée d’une session utilisateur à partir de l’Auth0 Dashboard.

Le flux de connexion est le suivant :

1. Lancer le flux d’authentification OIDC : le navigateur de l’utilisateur enverra une requête à Auth0 pour lancer le flux OIDC.
2. Définir le cookie SSO : Auth0 définira un cookie pour stocker les informations de l’utilisateur.
3. Effectuer l’échange de code et retourner le ID Token : Auth0 enverra une requête au serveur web et retournera le code. Le serveur web échangera le code contre un ID Token.
4. Définir le cookie d’authentification et envoyer la réponse : le serveur web renverra une réponse au navigateur et définira 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 subséquente : le cookie d’authentification de l’application sera envoyé avec chaque requête subséquente comme preuve que l’utilisateur est authentifié.

​

Comment 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 peut détecter si une session SSO Auth0 existe et demander à l’utilisateur s’il souhaite se connecter de nouveau en tant que ce même utilisateur.

Si c’est le cas, il est connecté sans avoir à saisir de nouveau ses informations d’identification auprès de l’IdP 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 nouveau ID Token, qui peut ensuite être utilisé pour gérer la nouvelle session locale de l’application.

Consultez la mise en œuvre 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é précédemment :

• Application Session : Vous devez déconnecter l’utilisateur de votre application Web en supprimant sa session.
• Auth0 session : Vous devez déconnecter l’utilisateur d’Auth0. Pour ce faire, redirigez l’utilisateur vers https://{yourDomain}/v2/logout. Rediriger l’utilisateur vers cette URL efface tous les cookies d’authentification unique définis par Auth0 pour l’utilisateur.
• fournisseur d’identité session : 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 Logout : https://{yourDomain}/v2/logout?federated.

Pour rediriger un utilisateur après la déconnexion, ajoutez le paramètre de chaîne de requête returnTo avec l’URL cible comme valeur : https://{yourDomain}/v2/logout?returnTo=http://www.example.com. Notez que vous devrez ajouter l’URL returnTo aux Allowed Logout URLs. Pour en savoir plus sur la façon de mettre cela en œuvre, consultez : Logout.

Le flux de déconnexion (sans inclure la déconnexion fédérée) se déroule comme suit :

1. Lancer le flux de déconnexion : Le flux de déconnexion est lancé depuis le navigateur, par exemple lorsque l’utilisateur clique sur un lien Logout. Une requête est alors envoyée au serveur Web.
2. Effacer la session locale de l’utilisateur : L’Application Session / le cookie de l’utilisateur sera effacé.
3. Rediriger le navigateur vers Auth0 Logout : Le navigateur de l’utilisateur sera redirigé vers l’URL de Logout d’Auth0.
4. Effacer le cookie SSO : Auth0 effacera le cookie SSO de l’utilisateur.
5. Rediriger vers l’URL post-déconnexion : Auth0 renverra une réponse de redirection et redirigera le navigateur de l’utilisateur vers le paramètre de chaîne de requête returnTo.

Voir la mise en œuvre 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 mettre en œuvre 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 ajouter comme claims d’autorisation dans le ID Token et valider ces claims dans votre application, une fois le token récupéré, afin de contrôler l’accès.

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

• En configurant et en utilisant l’Auth0 Authorization Extension.
• En utilisant des groupes Active Directory. Ceux-ci peuvent être utilisés avec l’Authorization Extension en mappant les groupes Active Directory aux groupes que vous définissez à l’aide de l’Authorization Extension.
• En ajoutant des metadata au profil de l’utilisateur à l’aide des 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 les groupes Active Directory.

Authorization Extension

À l’heure actuelle, l’Authorization Extension est principalement conçue pour appliquer une autorisation générale, 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 contrôler un accès plus granulaire (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 attribués à un groupe Admin qui leur permettra d’approuver les feuilles de temps. L’Authorization Extension permet de mapper des groupes à une appartenance à des groupes existante.

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

Lorsque vous installez l’Authorization Extension, elle crée une rule en arrière-plan, qui fait ce qui suit :

1. Déterminer l’appartenance de l’utilisateur à des groupes.
2. Stocker les renseignements sur l’appartenance de l’utilisateur à des groupes dans app_metadata.
3. Ajouter l’appartenance de l’utilisateur à des groupes au token sortant.
4. Vérifier que l’utilisateur a reçu 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 s’affichera sous Installed Extensions.

Lorsque vous cliquerez sur le lien pour ouvrir l’extension pour la première fois, vous devrez autoriser l’extension à accéder à votre compte Auth0. Si vous le faites, 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.

Une fois le groupe ajouté, vous pouvez cliquer dessus pour accéder à la section de gestion du groupe. Accédez à l’onglet Group Mappings et ajoutez un nouveau group mapping qui mappera 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 mapping s’affiche dans la liste.

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

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

​

Appliquer les permissions dans votre application

Lorsque vous avez installé l’Authorization Extension, une règle Auth0 a également été créée pour ajouter un claim authorization contenant tous les paramètres liés à l’autorisation pour un utilisateur donné. Les groups d’un utilisateur sont ajoutés comme sous-claim du claim authorization, sous le nom groups, et tous les groups auxquels l’utilisateur appartient sont ajoutés à ce claim sous forme de tableau. Voici un exemple de ce à quoi peut ressembler le payload JSON d’un ID Token lorsque les groups y sont listé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 du claim 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 consulter afin de déterminer s’il dispose des permissions nécessaires pour effectuer une certaine action en fonction de son appartenance à un groupe.

Consultez la mise en œuvre dans ASP.NET Core.