Passer au contenu principal
Dans ce scénario, nous allons créer une application Web pour une entreprise fictive nommée ExampleCo. L’application est destinée aux employés et aux contractuels d’ExampleCo. Les employés utiliseront leur annuaire d’entreprise existant (Active Directory), tandis que les contractuels seront gérés dans un répertoire d’utilisateurs distinct.

​
En bref

  • Auth0 prend en charge des normes ouvertes comme OAuth 2.0 et pour l’authentification et l’autorisation (voir Quel protocole utiliser)
  • OIDC prend en charge plusieurs flux d’autorisation différents — le plus approprié pour les applications Web étant le flux de code d’autorisation (voir Flux d’authentification)
  • Votre application sera configurée dans Auth0 en tant qu’application (voir Application)
  • Les fournisseurs d’identité seront configurés dans Auth0 en tant que Connexion (voir Connexions)
  • Auth0 fournit le widget Lock, qui permet aux utilisateurs de se connecter à l’application (voir Connexion de l’utilisateur)
  • L’application Web doit gérer l’état de la session pour conserver l’information indiquant que l’utilisateur est connecté. En parallèle, Auth0 et le fournisseur d’identité gèrent aussi les renseignements de session. (voir Gestion des sessions)
  • À l’inverse, la déconnexion d’un utilisateur implique aussi trois couches de gestion de session (voir Déconnexion de l’utilisateur)
  • Le contrôle d’accès peut être géré avec l’Authorization Extension d’Auth0 (voir Contrôle d’accès)
Par application Web traditionnelle, nous entendons une application qui utilise principalement le rendu côté serveur, les requêtes de page GET, POST et les témoins pour maintenir l’état. Cela contraste avec une SPA Web (application monopage), qui repose fortement sur du code JavaScript côté client appelant une API.

​
Le contexte

ExampleCo est une jeune entreprise de services-conseils. À l’heure actuelle, elle compte environ 100 employés et sous-traite aussi plusieurs activités à des entrepreneurs externes. La plupart des employés travaillent au bureau principal de l’entreprise, mais certaines équipes travaillent à distance. De plus, certains employés se rendent fréquemment chez les clients et travaillent à partir d’appareils mobiles. Tous les employés et les entrepreneurs externes doivent remplir leur feuille de temps chaque semaine à l’aide de tableurs. Le système actuel est inefficace, et l’entreprise a décidé de passer à une solution plus efficace et plus automatisée. L’entreprise a évalué plusieurs applications de feuilles de temps offertes sur le marché et a conclu qu’il serait plus rentable de créer sa propre solution à l’interne, puisqu’elle cherche pour le moment une application très simple. L’application sera développée avec ASP.NET Core, puisque ses développeurs utilisent déjà cette technologie et peuvent l’avoir prête en une semaine environ.

​
Objectifs et exigences

ExampleCo veut lancer rapidement la nouvelle solution. L’entreprise a donc choisi de commencer simplement et de la faire évoluer au fur et à mesure qu’elle recueille les commentaires de ses employés. L’application doit être accessible uniquement aux utilisateurs connectés. Chaque utilisateur aura un rôle et, selon ce rôle, il pourra effectuer certaines actions et consulter certaines données.

​
Authentification ou autorisation

ExampleCo veut authentifier et autoriser chaque utilisateur. L’authentification concerne l’identité : il s’agit de vérifier que l’utilisateur est bien celui qu’il prétend être. L’autorisation consiste à déterminer aux ressources auxquelles un utilisateur peut accéder et ce qu’il est autorisé à faire avec elles.
L’application de feuilles de temps d’ExampleCo doit prendre en charge deux rôles : Utilisateur et Admin :
  • Une personne ayant le rôle Utilisateur peut ajouter des entrées de feuille de temps en indiquant la date, l’application et le nombre d’heures travaillées. Le rôle Admin a également ce droit.
  • Les personnes ayant le rôle Utilisateur ne doivent avoir accès qu’à leurs propres entrées de feuille de temps.
  • Une personne ayant le rôle Admin peut aussi :
    • Approuver ou rejeter les entrées de feuille de temps d’autres utilisateurs.
    • Modifier la liste déroulante des applications (ajouter, modifier, supprimer).
Chaque utilisateur devra remplir ses feuilles de temps d’ici la fin de la semaine. Il pourra soit saisir ses feuilles de temps chaque jour, soit ajouter toutes les entrées de la semaine en une seule fois. Les feuilles de temps devront être examinées et approuvées par un Admin. Les entrées rejetées devront être mises à jour par chaque employé, puis soumises de nouveau pour approbation. L’entreprise utilise Active Directory pour tous ses employés, et ceux-ci se connecteront à l’application Timesheet à l’aide de leurs identifiants Active Directory. Les sous-traitants externes peuvent se connecter avec un nom d’utilisateur et un mot de passe. Les sous-traitants ne figurent pas dans l’annuaire d’entreprise d’ExampleCo. ExampleCo veut réduire au minimum les contraintes liées à la connexion des utilisateurs, tout en maintenant un niveau de sécurité adapté à l’opération : soumettre des entrées de feuille de temps présente moins de risque que de les approuver. Toutefois, les feuilles de temps approuvées servent à facturer les clients, donc la sécurité est bel et bien une exigence. La stratégie d’authentification doit être suffisamment flexible pour s’adapter à la croissance de l’entreprise. Par exemple, l’entreprise devrait pouvoir ajouter facilement des exigences d’authentification supplémentaires, comme l’, pour les Admins. La solution doit être accessible autant aux employés présents physiquement au bureau qu’à ceux qui travaillent à distance, sans les contraintes d’une connexion VPN. L’application doit donc être déployée chez un fournisseur infonuagique comme Heroku ou Microsoft Azure.
Schéma de la solution

​
En savoir plus