Skip to main content
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 sous-traitants d’ExampleCo. Les employés utiliseront leur annuaire d’entreprise existant (Active Directory), tandis que les sous-traitants seront gérés dans un référentiel d’utilisateurs distinct.

​
En bref

  • Auth0 prend en charge des normes ouvertes comme OAuth 2.0 et pour l’authentification et l’autorisation (consultez Quel protocole utiliser)
  • OIDC prend en charge plusieurs flux d’autorisation; le plus approprié pour les applications Web est le flux de code d’autorisation (consultez Flux d’authentification)
  • Votre application sera configurée dans Auth0 en tant qu’application (consultez Application)
  • Les fournisseurs d’identité seront configurés dans Auth0 en tant que connexion (consultez Connexions)
  • Auth0 fournit un widget Lock qui permet aux utilisateurs de se connecter à l’application (consultez Connexion de l’utilisateur)
  • L’application Web doit gérer l’état de la session pour savoir que l’utilisateur est connecté. Parallèlement, Auth0 et le fournisseur d’identité gèrent aussi les informations de session. (consultez Gestion de session)
  • À l’inverse, la déconnexion d’un utilisateur implique aussi trois couches de gestion de session (consultez Déconnexion de l’utilisateur)
  • Le contrôle d’accès peut être géré à l’aide de l’extension Authorization Extension d’Auth0 (consultez Contrôle d’accès)
Par application Web régulière, nous entendons une application qui utilise principalement le serveur, les requêtes de page GET et POST, ainsi que des cookies pour gérer l’état. À l’inverse, une application SPA Web (application monopage) repose largement sur du code Javascript côté client qui appelle une API.

​
Le contexte

ExampleCo est une jeune entreprise de services-conseils. À l’heure actuelle, elle compte environ 100 employés et confie aussi plusieurs activités à des sous-traitants externes. La plupart des employés travaillent au bureau principal de l’entreprise, mais certaines équipes travaillent à distance. De plus, certains employés se déplacent fréquemment chez les clients et travaillent sur des appareils mobiles. Tous les employés et les sous-traitants externes doivent remplir leurs feuilles de temps chaque semaine au moyen de feuilles de calcul. 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 en est arrivée à la conclusion qu’il serait plus rentable de créer sa propre solution à l’interne, puisqu’elle recherche 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 qu’ils peuvent la rendre prête en une semaine environ.

​
Objectifs et exigences

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

​
Authentification vs 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 devrait avoir accès et ce qu’il devrait être autorisé à faire avec celles-ci.
L’application de feuilles de temps d’ExampleCo doit prendre en charge deux rôles : User et Admin :
  • Une personne ayant le rôle User peut ajouter des entrées de feuille de temps en précisant la date, l’application et les heures travaillées. Le rôle Admin possède également ce droit.
  • Les personnes ayant le rôle User ne devraient avoir accès qu’à leurs propres entrées de feuilles de temps.
  • Une personne ayant le rôle Admin peut en plus :
    • approuver ou rejeter les entrées de feuilles de temps des autres utilisateurs.
    • modifier la liste déroulante des valeurs de l’application (ajouter, modifier, supprimer).
Chaque utilisateur devra remplir ses feuilles de temps d’ici la fin de la semaine. Il pourra soit choisir de saisir ses feuilles de temps chaque jour, soit ajouter en une seule fois les entrées pour toute la semaine. 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 les 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 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 risques que les approuver. Toutefois, les feuilles de temps approuvées sont utilisées pour la facturation des clients; la sécurité est donc essentielle. La stratégie d’authentification devrait être suffisamment flexible pour s’adapter à la croissance de l’entreprise. Par exemple, elle devrait pouvoir ajouter facilement des exigences d’authentification supplémentaires, comme l’, pour les Admins. La solution devrait être accessible à la fois aux employés physiquement présents au bureau de l’entreprise et à ceux qui travaillent à distance, sans nécessiter une connexion VPN. L’application devrait donc être déployée sur un fournisseur infonuagique comme Heroku ou Microsoft Azure.
Schéma de la solution

​
En savoir plus