Configurer l’accès pour les fournisseurs et les rôles

Effectué

Avec l’authentification utilisateur en place, votre application web de liste d’achats a besoin d’un moyen pour limiter l’accès à certaines pages aux utilisateurs qui ne sont pas connectés et pour autoriser la connexion uniquement via des fournisseurs spécifiques.

Nous examinerons la configuration et les rôles de routage dans Azure Static Web Apps pour optimiser l’accès utilisateur à notre application web.

Fichier de configuration pour Azure Static Web Apps

La configuration d’Azure Static Web Apps est définie dans le fichier staticwebapp.config.json, qui contrôle les paramètres suivants :

  • Routage
  • Authentification
  • Autorisation
  • Règles de secours
  • Remplacement des réponses HTTP
  • Définitions globales d’en-tête HTTP
  • Types MIME personnalisés

L’emplacement recommandé pour le staticwebapp.config.json se trouve dans le dossier défini par le paramètre app_location que nous avons choisi pendant le déploiement. Toutefois, le fichier peut être placé à n’importe quel emplacement au sein du dossier du code source de votre application.

Pour notre cas d’utilisation, nous examinerons la configuration du routage pour obtenir ce que nous voulons.

Restreindre les fournisseurs d’authentification

Dans une section précédente, nous avons vu que, par défaut, tous les fournisseurs d’authentification sont activés. Nous pouvons modifier cela en ajoutant des règles de routage à la configuration.

Par exemple, pour désactiver la connexion via le fournisseur GitHub, vous pouvez ajouter une règle d’acheminement comme celle-ci dans le fichier staticwebapp.config.json.

{
  "routes": [
    {
      "route": "/.auth/login/github",
      "statusCode": 404
    }
  ]
}

Nous forçons la route /.auth/login/github utilisée pour l’authentification auprès du fournisseur GitHub à retourner une erreur 404 (Introuvable) afin que les utilisateurs ne puissent pas y accéder. Vous pouvez ajouter autant de règles d’itinéraires que vous souhaitez pour désactiver tous les fournisseurs que vous ne souhaitez pas utiliser.

Sécuriser les routes avec des rôles

Les itinéraires sont accessibles par défaut à tout le monde sans aucune restriction. Vous pouvez lsécuriser les itinéraires en y ajoutant un ou plusieurs noms de rôles dans le tableau allowedRoles de la règle. Par défaut, chaque utilisateur appartient au rôle anonymous intégré et tous les utilisateurs connectés sont membres du rôle authenticated.

Par exemple, pour limiter un itinéraire aux seuls utilisateurs authentifiés, ajoutez le rôle authenticated intégré au tableau allowedRoles.

{
  "routes": [
    {
      "route": "/profile",
      "allowedRoles": ["authenticated"]
    }
  ]
}

Avec cette configuration, si un utilisateur non authentifié tente d’accéder à l'itinéraire /profile, une erreur 401 (non autorisée) est retournée.

Vous pouvez également restreindre des méthodes HTTP spécifiques pour une route donnée, comme suit :

{
  "routes": [
    {
      "route": "/profile",
      "methods": ["PUT", "POST", "DELETE"],
      "allowedRoles": ["authenticated"]
    }
  ]
}

Dans cet exemple, tous les utilisateurs peuvent accéder à la méthode GET sur l'itinéraire /profile, mais seuls les utilisateurs authentifiés peuvent utiliser PUT, POST ou DELETE.

Utiliser un caractère générique

Vous pouvez utiliser un caractère générique à la fin de l’itinéraire pour faire correspondre tous les itinéraires suivant le modèle de base. Par exemple, pour restreindre toutes les URL commençant par /api pour les utilisateurs authentifiés, vous pouvez écrire :

{
  "routes": [
    {
      "route": "/api/*",
      "allowedRoles": ["authenticated"]
    }
  ]
}

Étapes suivantes

Nous allons ensuite implémenter des restrictions d’accès dans notre application.