Partager via

Authentification locale dans le générateur d’API de données

  • Article

Lors du développement d’une solution à l’aide du générateur d’API de données localement ou lors de l’exécution locale du générateur d’API de données, vous devez tester les options d’authentification et d’autorisation configurées en simulant une demande avec un rôle ou une revendication spécifique.

Pour simuler une demande authentifiée sans configurer de fournisseur d’authentification (comme Microsoft Entra ID, par exemple), vous pouvez utiliser les Simulator fournisseurs d’authentification ou StaticWebApps :

Utiliser le Simulator fournisseur

Simulator est un fournisseur d’authentification configurable qui indique au moteur du générateur d’API de données de traiter toutes les requêtes comme authentifiées.

  • Au minimum, toutes les demandes sont évaluées dans le contexte du rôle Authenticatedsystème .
  • Si vous le souhaitez, la demande est évaluée dans le contexte de n’importe quel rôle indiqué dans l’en-tête X-MS-API-ROLE Http.

Notes

Bien que le rôle souhaité soit respecté, les autorisations d’autorisation définissant des stratégies de base de données ne fonctionnent pas, car les revendications personnalisées ne peuvent pas être définies pour l’utilisateur authentifié auprès du Simulator fournisseur. Passez à la section Utiliser le fournisseur pour tester les StaticWebApps stratégies d’autorisation de base de données.

1. Mettre à jour le fournisseur d’authentification de configuration du runtime

Vérifiez que dans le fichier de configuration, vous utilisez le fournisseur d’authentification et development le Simulator mode est spécifié. Reportez-vous à cet exemple de host section de configuration :

"host": {
  "mode": "development",
  "authentication": {
    "provider": "Simulator"
  }
}

2. Spécifier le contexte de rôle de la demande

Avec Simulator comme fournisseur d’authentification du générateur d’API de données, aucun en-tête personnalisé n’est nécessaire pour définir le contexte de rôle sur le rôle Authenticatedsystème :

curl --request GET \
  --url http://localhost:5000/api/books \

Pour définir le contexte de rôle sur n’importe quel autre rôle, y compris le rôle Anonymoussystème , l’en-tête X-MS-API-ROLE doit être inclus avec le rôle souhaité :

curl --request GET \
  --url http://localhost:5000/api/books \
  --header 'X-MS-API-ROLE: author' \

Utiliser le StaticWebApps fournisseur

Le StaticWebApps fournisseur d’authentification demande au générateur d’API de données de rechercher un ensemble d’en-têtes HTTP uniquement présents lors de l’exécution dans un environnement Static Web Apps. Le client définit ces en-têtes HTTP lors de l’exécution locale pour simuler un utilisateur authentifié, y compris l’appartenance à un rôle ou les revendications personnalisées.

Notes

Les instances fournies par le client de l’en-tête Http, X-MS-CLIENT-PRINCIPAL, fonctionnent uniquement lors du développement local, car les environnements de production Azure Static Web Apps suppriment toutes les instances fournies par le client de cet en-tête.

Assurez-vous que dans le fichier de configuration, vous utilisez le fournisseur d’authentification StaticWebApps . Reportez-vous à cet exemple de host section de configuration :

"host": {
  "mode": "development",
  "authentication": {
    "provider": "StaticWebApps"
  }
}

1. Envoyer des requêtes fournissant un en-tête généré X-MS-CLIENT-PRINCIPAL

Une fois le générateur d’API de données exécuté localement et configuré pour utiliser le StaticWebApps fournisseur d’authentification, vous pouvez générer manuellement un objet principal client à l’aide du modèle suivant :

{  
  "identityProvider": "test",
  "userId": "12345",
  "userDetails": "john@contoso.com",
  "userRoles": ["author", "editor"]
}

Les métadonnées utilisateur authentifiées de Static Web App ont les propriétés suivantes :

Propriété Description
IdentityProvider Toute valeur de chaîne.
userId Identificateur unique de l’utilisateur.
userDetails Nom d’utilisateur ou adresse e-mail de l’utilisateur.
userRoles Tableau des rôles affectés à l’utilisateur.

Notes

Comme indiqué dans Static Web Apps documentation, l’en-tête X-MS-CLIENT-PRINCIPAL ne contient pas le claims tableau.

Pour être transmise avec l’en-tête X-MS-CLIENT-PRINCIPAL , la charge utile JSON doit être encodée en Base64. Pour ce faire, vous pouvez utiliser n’importe quel outil en ligne ou hors connexion. L’un de ces outils est DevToys. Exemple de charge utile encodée en Base64 qui représente le JSON précédemment référencé :

eyAgCiAgImlkZW50aXR5UHJvdmlkZXIiOiAidGVzdCIsCiAgInVzZXJJZCI6ICIxMjM0NSIsCiAgInVzZXJEZXRhaWxzIjogImpvaG5AY29udG9zby5jb20iLAogICJ1c2VyUm9sZXMiOiBbImF1dGhvciIsICJlZGl0b3IiXQp9

La requête cURL suivante simule un utilisateur authentifié qui récupère la liste des enregistrements d’entité disponibles Book dans le contexte du author rôle :

curl --request GET \
  --url http://localhost:5000/api/books \
  --header 'X-MS-API-ROLE: author' \
  --header 'X-MS-CLIENT-PRINCIPAL: eyAgCiAgImlkZW50aXR5UHJvdmlkZXIiOiAidGVzdCIsCiAgInVzZXJJZCI6ICIxMjM0NSIsCiAgInVzZXJEZXRhaWxzIjogImpvaG5AY29udG9zby5jb20iLAogICJ1c2VyUm9sZXMiOiBbImF1dGhvciIsICJlZGl0b3IiXQp9'

Contenu connexe