Sécuriser le frontend du serveur vers le service Web

ASP.NET Core Frontend, côté serveur de votre application, doit remporter les rôles qui lui permettront d’accéder au backend sécurisé de votre application.
Dans Partie 8: sécuriser un service Web dans un service d’application AzureJ’ai montré comment créer un enregistrement d’application pour un service Web en cours d’exécution dans un service d’application. L’enregistrement des applications de ce service Web a défini un ou plusieurs rôles que le code du service Web s’attend à ce que tout frontend côté serveur fournisse avant que le service Web exécute l’une des demandes du frontend.
Dans cet article, je vais me procéder à la création d’un enregistrement d’application pour votre frontend côté serveur (par exemple, ASP.NET Core) qui rend ces rôles à la disposition de votre application Frontend, ainsi que le code pour les deux prétendre passer ces rôles sur le service Web.
Création d’un enregistrement d’application Frontend
Pour créer une inscription à votre application pour votre frontend, surfez sur le portail Azure et ouvrez le Inscriptions aux applications page. Alors:
- À l’extrémité gauche du menu en haut de cette page, cliquez sur + Nouvelle inscription. Donnez un nom à votre inscription qui fait référence à votre frontend (j’ai utilisé WarehouseMgMtregFrontendSpnet).
- Dans la liste de choix des boutons radio suivants, je suppose que vous créez une application à utiliser en interne, donc vous voulez le premier choix: Comptes dans ce répertoire organisationnel uniquement. Le Autres options Y a-t-il pour soutenir les organisations qui ont plusieurs locataires Azure, des fournisseurs tiers vendant des solutions aux utilisateurs d’Azure et des produits accessibles par des utilisateurs aléatoires (par exemple, vos clients).
- Cliquez sur Registre bouton pour enregistrer votre inscription à votre application.
Si vous créez cette inscription pour que quelqu’un d’autre puisse modifier, dans le menu à gauche, sélectionnez le Propriétaires Choix et ajouter l’utilisateur qui gérera l’enregistrement en tant que propriétaire pour l’enregistrement de l’application.
Compléter l’enregistrement de l’application côté serveur
Étant donné que vous créez un frontend côté serveur (par exemple, ASP.NET Core), vous pouvez rendre difficile les applications de réclamer cet enregistrement en obligeant la demande de frontend pour fournir des informations d’identification, soit une chaîne secrète ou un certificat.
Pour spécifier ces informations d’identification, dans le menu de l’enregistrement de l’application à gauche, élargissez le Gérer nœud et sélectionner Certificats et secrets Pour afficher la page Certificats et Secrets à droite. Pour simplifier cet exemple, je vais vous promener dans l’ajout d’un secret (l’utilisation d’un certificat nécessite vraiment l’utilisation du coffre-fort Azure que je couvrirai dans un post ultérieur).
Pour ajouter une clé secrète:
- Cliquez sur le Secrets des clients languette.
- Lorsque l’onglet s’affiche, cliquez sur le + Nouveau secret client secret choix d’ouvrir un panneau à droite.
- Dans ce panneau, entrez une description pour documenter votre secret (j’ai utilisé WarehouseMgmtFrontendRegSecret) et fixé une période d’expiration (à des fins de développement, j’ai choisi la période la plus longue fournie – 730 jours).
- Cliquez sur Ajouter bouton pour créer votre secret et remettre à la page principale.
- Lorsque votre nouveau secret apparaît dans la liste de cette page, utilisez l’icône de copie pour copier le Valeur Entrée pour votre secret et enregistrez-le quelque part (selon mon expérience, si vous revenez sur cette page, vous ne pourrez pas nécessairement voir ou copier ce secret).
Facultatif: accepter les jetons d’authentification
Vous pouvez également spécifier une URL où les jetons d’authentification doivent être envoyés pour votre frontend (Remarque: pas Vos jetons d’autorisation pour parler à votre service Web – qui vient plus tard). Ceci est facultatif pour un frontend côté serveur et peut être ignoré si vous pouvez supposer que votre utilisateur est toujours connecté avant d’exécuter votre frontend (par exemple, si c’est vous, en développement).
Pour ajouter cette URL, dans le menu à gauche de l’enregistrement de votre application, élargissez le Gérer nœud et sélectionner Autorisation.
Dans le menu d’enregistrement de votre application à gauche, élargissez le Gérer nœud et sélectionner Authentification Pour afficher la page de configurations de plate-forme. Sur cette page, cliquez sur le + Ajouter une plate-forme Choix pour afficher le panneau des applications Web à droite.
Dans le panneau des applications Web, choisissez le Web choix. Qui vous déplacera vers la deuxième page du panneau, où vous devez saisir l’URL du service d’applications de votre frontend, suivi de toute chaîne conforme à l’URL que vous souhaitez, bien que «/ sigin-oïdc» soit la convention (par exemple, pour mon service d’applications, j’utiliserais https://warehousemgmtfrontendaspnet.azurewebsites.net/signin-oidc
).
Ensuite, faites défiler vers le bas du panneau et vérifiez le Tokens ID pour… choix avant de cliquer sur le Configurer bouton pour fermer le panneau.
Spécification des rôles
Vous devez maintenant spécifier lequel de tous les rôles définis dans l’enregistrement de l’application de votre service Web sont ceux que vous souhaitez que votre frontend côté client utilise. Pour ce faire:
- Dans le menu à gauche de votre inscription à votre application, sous le Gérer Node Sélectionnez le Autorisation API choix d’afficher une nouvelle page à droite.
- À l’extrémité gauche du menu à travers la page, sélectionnez le + Ajouter une autorisation choix d’afficher le Demander des autorisations API panneau à droite.
- Dans ce panneau, sélectionnez le APIS que mon organisation utilise languette.
- Dans cet onglet, dans le Applications de votre répertoireTapez le nom de l’enregistrement de l’application de votre service Web. Lorsqu’il apparaît, sélectionnez-le.
- Pour attribuer un ou plusieurs des rôles que vous avez définis dans l’enregistrement de l’application de votre service Web, cliquez sur le Autorisation de demande Boîte pour afficher les rôles que vous avez définis.
- Vérifiez le (s) rôle (s) que vous souhaitez que votre application frontale ait.
- Cliquez sur Ajouter la permission Bouton pour fermer le panneau et ajouter le rôle à votre liste de rôles à votre page API Autorisations.
Lorsque votre liste de rôles rafraîchit, leur Statut la colonne affichera un panneau d’avertissement et un message commençant Non accordé pour…. Vous devez accorder son consentement à ces rôles maintenant (c’est quelque chose d’autre que vous ne pouvez pas faire et peut obliger un administrateur à surfer à cet enregistrement pour terminer ce processus).
Pour accorder son consentement, toujours sur le Autorisation API Page, en haut de la liste des autorisations, cliquez sur la coche verte à côté du Accorder le consentement de l’administrateur pour… choix et cliquez Oui Dans la zone de texte «êtes-vous sûr» qui apparaît. Tous les rôles que vous avez attribués auront leur consentement (si vous le souhaitez, vous pouvez utiliser l’ellipse –…— À l’extrémité droite de chaque rôle pour supprimer sélectivement le consentement de l’administrateur).
Vous êtes maintenant prêt à demander à votre application de frontend de réclamer cet enregistrement d’application avec ses rôles, puis de passer ces rôles à votre service Web.
Dépannage
Il vaut la peine de prendre un moment pour utiliser l’outil fourni pour vérifier correctement l’inscription de votre service Web.
Dans le menu en bas à gauche de l’enregistrement de votre application, sélectionnez Assistant d’intégration pour ouvrir l’assistant à droite. Dans la liste déroulante, sélectionnez Application Web.
Après avoir effectué votre sélection dans la première liste déroulante, cliquez n’importe où sur la page pour fermer la liste et révéler le Cette application appelle-t-elle des API? option. Réglez la bascule en dessous Oui puis cliquez sur le Évaluer l’enregistrement de mon application bouton.
L’assistant affichera une liste de recommandations requises et facultatives à mettre en œuvre et un ensemble de recommandations que vous ne devrait pas mettre en œuvre. À condition que vous ayez des marques de contrôle vertes sur toutes les requises et ne devriez pas recommandations, l’enregistrement de votre application doit être prêt à l’emploi. (Vous pouvez ignorer les recommandations facultatives, du moins pour l’instant).
Réclamer l’enregistrement de l’application
Votre prochaine étape consiste à ajouter le code à votre application côté serveur pour réclamer l’enregistrement que vous venez de créer et de transmettre les rôles qu’il spécifie à votre service Web.
Pour ce faire, dans votre outil de développement (Visual Studio ou Visual Studio Code), pour un frontend Core ASP.NET, ajoutez le Package Microsoft.Identity.Web Nuget. Dans votre fichier programme.cs, assurez-vous d’avoir ajouté à la fois l’utilisation et l’utilisation de l’utilisation au pipeline de votre application avec du code comme celui-ci (ceux-ci doivent suivre votre appel à l’insertion):
app.UseAuthentication();
app.useAuthorization();
Toujours dans votre fichier programme.cs, ajoutez ce code en haut de votre fichier (par exemple, juste après l’appel à CreateBuilder
est bon) pour réclamer votre enregistrement, acquérir le jeton d’autorisation vos besoins de demande et le stocker dans un cache pour que votre code puisse utiliser plus tard:
builder.Services.AddAuthentication(OpenIdConnectDefaults.AuthenticationScheme)
.AddMicrosoftIdentityWebApp(builder.Configuration)
.EnableTokenAcquisitionToCallDownstreamApi()
.AddInMemoryTokenCaches();
Le jeton dans le cache (une chaîne cryptée) représente les rôles qui ont été accordés dans l’enregistrement de votre application.
Ce code prévoit de trouver toutes les informations dont il a besoin pour que votre frontend réclame son enregistrement d’application dans votre fichier appsettings.json, dans une section appelée Azouread. Cela comprend:
- La clé secrète que vous avez créée pour l’enregistrement de votre application
- L’ID client et l’ID d’application à partir de la page d’aperçu de l’enregistrement de l’application de votre frontend
- L’URL du fournisseur d’identité que vous utilisez (si vous utilisez Microsoft Entra ID comme fournisseur d’identité, son URL est https://login.microsoftonline.com/)
- Le domaine du service d’applications de votre frontend (c’est-à-dire,
<your frontend app service>.azurewebsites.net
).
Une section Azuread avec les bons noms de propriétés a cette structure (j’ai supposé que vous utilisez le «/ sigin-oïdc» conventionnel pour l’URL de redirection de votre frontend):
"AzureAd": {
"Instance": "https://login.microsoftonline.com/",
"Domain": "<name of your app service>.azurewebsites.net",
"ClientId": "<Application (Client) Id from the App Registration’s Overview page>",
"TenantId": "<Directory (tenant) Id from the App Registration’s Overview page>",
"ClientSecret": "<Client secret>",
"CallbackPath": "/signin-oidc"
},
Voici à quoi ressemblerait une section typique d’Azuread:
"AzureAd": {
"Instance": "https://login.microsoftonline.com/",
"Domain": "warehousemgmtfrontendaspnet.azurewebsites.net",
"TenantId": "e98…-…-…-…-…",
"ClientId": "80…-…-…-…-…",
"ClientSecret": "Hp68…,
"CallbackPath": "/signin-oidc"
},
Appeler le service Web
Enfin, dans le code où vous appelez votre service Web, vous devez récupérer le jeton à partir du cache de jeton que vous avez chargé dans votre fichier Program.cs et ajouter le jeton comme en-tête d’autorisation à votre demande HTTP.
Pour soutenir cela, dans le constructeur de la page de rasoir ou du contrôleur où vous appelez le service Web, vous devez saisir ces objets (ceux-ci s’ajoutent à la ILogger
Objet que votre code acquiert probablement déjà à partir de la collection de services d’Asp.net Core):
- Itokenacquisition: Cet objet vous permettra de tirer votre jeton d’accès à partir du cache de votre application
- Iconfiguration: pour extraire les informations de votre fichier appsettings.json
En conséquence, un constructeur typique avec ses champs de support dans une page de rasoir ressemblerait à ceci:
private readonly ILogger<HomeController> logger;
private readonly ITokenAcquisition tokenAcquisition;
private readonly IConfiguration config;
public IndexModel(ILogger<IndexModel> logger,
ITokenAcquisition tokenAcquisition,
IConfiguration config)
{
this.logger = logger;
this.tokenAcquisition = tokenAcquisition;
this.config = config;
}
Ensuite, vous devrez extraire la chaîne cryptée (votre jeton d’accès) à partir du cache où vous l’avez chargé dans votre fichier programme.cs. Vous tirez ce jeton en utilisant le GetAccessTokenForAppAsync
méthode de ITokenAcquisition
Objet que vous avez attrapé dans votre page ou constructeur de contrôleur.
Vous devez passer le GetAccessTokenForAppAsync
Méthode deux paramètres:
- L’URL de l’ID d’application de votre service Web (disponible à partir de la page d’enregistrement de votre service Web de votre service Web) avec «/.default» cloué à la fin (cet identifiant sera probablement dans le format
api:<Web service client id>
) - Le locantid de votre fichier appsettings.json
Voici ce code:
string accessToken = await tokenAcquisition.GetAccessTokenForAppAsync(
"<Web service Application ID URL>/.default",
tenant: config["AzureAd:TenantId"]);
Une fois que vous avez le jeton, vous pouvez l’utiliser pour générer un en-tête d’autorisation de type Bearer
et ajoutez cet en-tête aux en-têtes de demande par défaut de votre demande HTTP, comme celle-ci (ce code ajoute également un ID de corrélation à la demande de prise en charge du suivi de la demande):
HttpClient hc = new();
hc.DefaultRequestHeaders.Authorization
= new AuthenticationHeaderValue("Bearer", accessToken);
hc.DefaultRequestHeaders.Add("X-Correlation-ID",
new string[] { Guid.NewGuid().ToString() });
HttpResponseMessage resp = await hc.GetAsync("<URL for Web service>");
Tu peux maintenant Déployez votre frontend côté serveur à son service d’applications et surfez-le pour voir si cela fonctionne (et si ce n’est pas le cas, vous voudrez peut-être consulter mon article précédent sur le débogage, CODING AZURE 6: Débogage et journalisation d’une application dans un service d’application Azure.
Vous pouvez également tester votre frontend localement à partir de votre outil de développement, à condition que vous ayez ajouté l’URL locale que votre frontend se déroule sur la liste CORS de votre service d’applications.
Étapes suivantes
Il y a plus que vous pouvez faire ici pour sécuriser l’accès entre votre service Web et son frontend. Dans un article ultérieur, par exemple, j’intégrerai la gestion des API Web dans cette application et restreigne l’accès aux services d’application de mon service Web pour uniquement les demandes provenant du service d’applications de mon frontend (avec quelques mises en garde). Je vais également déplacer toutes les informations sensibles dans mon fichier AppSettings.json dans le coffre-clés Azure.
Vous pouvez également envisager d’ajouter une passerelle d’application avec un Pare-feu d’application Web au service d’applications de votre service Web et utilisez-le pour accepter uniquement les demandes des adresses TCP sortantes de votre service d’application Frontend (comme je l’ai fait avec le Base de données Azure SQL).
Mais, bien que le service Web backend soit sécurisé, l’application Frontend ne l’est pas. Dans mon prochain post, je vais couvrir comment attribuer des autorisations à votre frontend que vous pouvez vérifier dans le code de votre frontend.
Source link