Utilisation avancée des paramètres d’authentification et d’autorisation dans Azure App ServiceAdvanced usage of authentication and authorization in Azure App Service

Cet article vous explique comment personnaliser les paramètres d’authentification et d’autorisation intégrés dans App Service, et comment gérer les identités à partir de votre application.This article shows you how to customize the built-in authentication and authorization in App Service, and to manage identity from your application.

Pour commencer rapidement, consultez l’un des didacticiels suivants :To get started quickly, see one of the following tutorials:

Utiliser plusieurs fournisseurs de connexionUse multiple sign-in providers

La configuration du portail n’offre pas de solution clé en main pour présenter à vos utilisateurs plusieurs fournisseurs de connexion (telles que Facebook et Twitter).The portal configuration doesn't offer a turn-key way to present multiple sign-in providers to your users (such as both Facebook and Twitter). Toutefois, il est relativement simple d’ajouter cette fonctionnalité à votre application.However, it isn't difficult to add the functionality to your app. Voici la procédure à suivre :The steps are outlined as follows:

Tout d’abord, sur la page Authentification / Autorisation du portail Azure, configurez chaque fournisseur d’identité que vous souhaitez activer.First, in the Authentication / Authorization page in the Azure portal, configure each of the identity provider you want to enable.

Sous Mesure à prendre quand une demande n’est pas authentifiée, sélectionnez Autoriser les requêtes anonymes (aucune action) .In Action to take when request is not authenticated, select Allow Anonymous requests (no action).

Dans la page de connexion, la barre de navigation ou tout autre emplacement de votre application, ajoutez un lien de connexion pour chacun des fournisseurs que vous avez activés (/.auth/login/<provider>).In the sign-in page, or the navigation bar, or any other location of your app, add a sign-in link to each of the providers you enabled (/.auth/login/<provider>). Par exemple :For example:

<a href="/.auth/login/aad">Log in with Azure AD</a>
<a href="/.auth/login/microsoftaccount">Log in with Microsoft Account</a>
<a href="/.auth/login/facebook">Log in with Facebook</a>
<a href="/.auth/login/google">Log in with Google</a>
<a href="/.auth/login/twitter">Log in with Twitter</a>

Lorsque l’utilisateur clique sur l’un des liens, la page de connexion respective s’ouvre pour que l’utilisateur se connecte.When the user clicks on one of the links, the respective sign-in page opens to sign in the user.

Pour rediriger l’utilisateur post-connexion vers une URL personnalisée, utilisez le paramètre de chaîne de requête post_login_redirect_url (à ne pas confondre avec l’URI de redirection de votre configuration de fournisseur d’identité).To redirect the user post-sign-in to a custom URL, use the post_login_redirect_url query string parameter (not to be confused with the Redirect URI in your identity provider configuration). Par exemple, pour diriger l’utilisateur vers /Home/Index après sa connexion, utilisez le code HTML suivant :For example, to navigate the user to /Home/Index after sign-in, use the following HTML code:

<a href="/.auth/login/<provider>?post_login_redirect_url=/Home/Index">Log in</a>

Valider les jetons des fournisseursValidate tokens from providers

Dans une connexion dirigée par le client, l'application connecte manuellement l'utilisateur au fournisseur, puis soumet le jeton d'authentification à App Service pour validation (voir Flux d'authentification).In a client-directed sign-in, the application signs in the user to the provider manually and then submits the authentication token to App Service for validation (see Authentication flow). Cette validation proprement dite ne vous octroie pas l'accès aux ressources souhaitées, mais une validation réussie vous conférera un jeton de session que vous pourrez utiliser pour accéder aux ressources de l'application.This validation itself doesn't actually grant you access to the desired app resources, but a successful validation will give you a session token that you can use to access app resources.

Pour valider le jeton du fournisseur, l'application App Service doit d'abord être configurée avec le fournisseur souhaité.To validate the provider token, App Service app must first be configured with the desired provider. Au moment de l'exécution, après avoir récupéré le jeton d'authentification auprès de votre fournisseur, envoyez-le à /.auth/login/<provider> pour validation.At runtime, after you retrieve the authentication token from your provider, post the token to /.auth/login/<provider> for validation. Par exemple :For example:

POST https://<appname>.azurewebsites.net/.auth/login/aad HTTP/1.1
Content-Type: application/json

{"id_token":"<token>","access_token":"<token>"}

Le format du jeton varie légèrement selon le fournisseur.The token format varies slightly according to the provider. Pour plus de détails, consultez le tableau suivant :See the following table for details:

Valeur du fournisseurProvider value Requis dans le corps de la demandeRequired in request body CommentairesComments
aad {"access_token":"<access_token>"}
microsoftaccount {"access_token":"<token>"} La propriété expires_in est facultative.The expires_in property is optional.
Lors de la demande de jeton à partir des services Live, demandez toujours l'étendue wl.basic.When requesting the token from Live services, always request the wl.basic scope.
google {"id_token":"<id_token>"} La propriété authorization_code est facultative.The authorization_code property is optional. Lorsqu'elle est spécifiée, elle peut également être accompagnée de la propriété redirect_uri.When specified, it can also optionally be accompanied by the redirect_uri property.
facebook {"access_token":"<user_access_token>"} Utilisez un jeton d'accès utilisateur valide à partir de Facebook.Use a valid user access token from Facebook.
twitter {"access_token":"<access_token>", "access_token_secret":"<acces_token_secret>"}

Si le jeton du fournisseur est validé, l'API renvoie un authenticationToken dans le corps de la réponse. Il s'agit de votre jeton de session.If the provider token is validated successfully, the API returns with an authenticationToken in the response body, which is your session token.

{
    "authenticationToken": "...",
    "user": {
        "userId": "sid:..."
    }
}

Une fois en possession de ce jeton de session, vous pouvez accéder aux ressources d'application protégées en ajoutant l'en-tête X-ZUMO-AUTH à vos requêtes HTTP.Once you have this session token, you can access protected app resources by adding the X-ZUMO-AUTH header to your HTTP requests. Par exemple :For example:

GET https://<appname>.azurewebsites.net/api/products/1
X-ZUMO-AUTH: <authenticationToken_value>

Déconnexion d’une sessionSign out of a session

Les utilisateurs peuvent initier une déconnexion en envoyant une requête GET au point de terminaison /.auth/logout de l’application.Users can initiate a sign-out by sending a GET request to the app's /.auth/logout endpoint. La requête GET effectue les opérations suivantes :The GET request does the following:

  • Efface les cookies d’authentification de la session active.Clears authentication cookies from the current session.
  • Supprime du magasin de jetons les jetons de l’utilisateur actuel.Deletes the current user's tokens from the token store.
  • Pour Azure Active Directory et Google, effectue une déconnexion côté serveur sur le fournisseur d’identité.For Azure Active Directory and Google, performs a server-side sign-out on the identity provider.

Voici un lien de déconnexion simple dans une page web :Here's a simple sign-out link in a webpage:

<a href="/.auth/logout">Sign out</a>

Par défaut, une déconnexion réussie redirige le client vers l’URL /.auth/logout/done.By default, a successful sign-out redirects the client to the URL /.auth/logout/done. Vous pouvez modifier la page de redirection après déconnexion en ajoutant le paramètre de requête post_logout_redirect_uri.You can change the post-sign-out redirect page by adding the post_logout_redirect_uri query parameter. Par exemple :For example:

GET /.auth/logout?post_logout_redirect_uri=/index.html

Il est recommandé d’encoder la valeur de post_logout_redirect_uri.It's recommended that you encode the value of post_logout_redirect_uri.

Lorsque vous utilisez une URL complète, celle-ci doit être hébergée dans le même domaine, ou configurée comme URL de redirection externe autorisée pour votre application.When using fully qualified URLs, the URL must be either hosted in the same domain or configured as an allowed external redirect URL for your app. Dans l’exemple suivant, pour rediriger vers l’URL https://myexternalurl.com qui n’est pas hébergée dans le même domaine :In the following example, to redirect to https://myexternalurl.com that's not hosted in the same domain:

GET /.auth/logout?post_logout_redirect_uri=https%3A%2F%2Fmyexternalurl.com

Exécutez la commande suivante dans Azure Cloud Shell :Run the following command in the Azure Cloud Shell:

az webapp auth update --name <app_name> --resource-group <group_name> --allowed-external-redirect-urls "https://myexternalurl.com"

Conserver les fragments d’URLPreserve URL fragments

Lorsque des utilisateurs se connectent à votre application, ils veulent être redirigés vers la même section de la même page, par exemple, /wiki/Main_Page#SectionZ.After users sign in to your app, they usually want to be redirected to the same section of the same page, such as /wiki/Main_Page#SectionZ. Toutefois, étant donné que des fragments d’URL (par exemple, #SectionZ) ne sont jamais envoyés au serveur, ils ne sont pas conservés par défaut après que la connexion OAuth est terminée et redirige vers votre application.However, because URL fragments (for example, #SectionZ) are never sent to the server, they are not preserved by default after the OAuth sign-in completes and redirects back to your app. Les utilisateurs vivent ensuite une expérience médiocre quand ils ont besoin d’accéder à nouveau à l’ancre souhaitée.Users then get a suboptimal experience when they need to navigate to the desired anchor again. Cette limitation s’applique à toutes les solutions d’authentification côté serveur.This limitation applies to all server-side authentication solutions.

Dans l’authentification App Service, vous pouvez conserver des fragments d’URL dans le cadre de la connexion OAuth.In App Service authentication, you can preserve URL fragments across the OAuth sign-in. Pour ce faire, définissez un paramètre d’application nommé WEBSITE_AUTH_PRESERVE_URL_FRAGMENT sur true.To do this, set an app setting called WEBSITE_AUTH_PRESERVE_URL_FRAGMENT to true. Vous pouvez le faire dans le portail Azure, ou simplement exécuter la commande suivante dans Azure Cloud Shell :You can do it in the Azure portal, or simply run the following command in the Azure Cloud Shell:

az webapp config appsettings set --name <app_name> --resource-group <group_name> --settings WEBSITE_AUTH_PRESERVE_URL_FRAGMENT="true"

Accéder aux revendications d’utilisateurAccess user claims

App Service transmet des revendications d’utilisateur à votre application au moyen d’en-têtes spéciaux.App Service passes user claims to your application by using special headers. Les demandes externes ne sont pas autorisées à définir ces en-têtes. Ces derniers ne s’affichent donc que s’ils sont définis par App Service.External requests aren't allowed to set these headers, so they are present only if set by App Service. Voici quelques exemples d’en-têtes :Some example headers include:

  • X-MS-CLIENT-PRINCIPAL-NAMEX-MS-CLIENT-PRINCIPAL-NAME
  • X-MS-CLIENT-PRINCIPAL-IDX-MS-CLIENT-PRINCIPAL-ID

Tout code, quels que soient le langage ou l’infrastructure utilisés, peut trouver les informations qu’il recherche dans ces en-têtes.Code that is written in any language or framework can get the information that it needs from these headers. Dans le cas d’applications ASP.NET 4.6, le paramètre ClaimsPrincipal est automatiquement défini sur les valeurs appropriées.For ASP.NET 4.6 apps, the ClaimsPrincipal is automatically set with the appropriate values. Toutefois, ASP.NET Core ne fournit pas d’intergiciel d’authentification qui s’intègre aux revendications d’utilisateur App Service.ASP.NET Core, however, doesn't provide an authentication middleware that integrates with App Service user claims. Pour une solution de contournement, consultez MaximeRouiller.Azure.AppService.EasyAuth.For a workaround, see MaximeRouiller.Azure.AppService.EasyAuth.

Votre application peut également obtenir des détails supplémentaires sur l’utilisateur authentifié en appelant /.auth/me.Your application can also obtain additional details on the authenticated user by calling /.auth/me. Les Kits de développement logiciel (SDK) serveur de Mobile Apps offrent des méthodes d’assistance permettant de manipuler ces données.The Mobile Apps server SDKs provide helper methods to work with this data. Pour plus d’informations, consultez Comment utiliser le Kit de développement logiciel Node.js dans Azure Mobile Apps, et Utiliser le Kit de développement logiciel (SDK) de serveur principal .NET pour Azure Mobile Apps.For more information, see How to use the Azure Mobile Apps Node.js SDK, and Work with the .NET backend server SDK for Azure Mobile Apps.

Récupérer des jetons dans le code d’applicationRetrieve tokens in app code

À partir de votre code serveur, les jetons spécifiques au fournisseur sont ajoutés dans l’en-tête de requête, afin que vous puissiez y accéder facilement.From your server code, the provider-specific tokens are injected into the request header, so you can easily access them. Le tableau suivant présente les noms d’en-tête de jeton possibles :The following table shows possible token header names:

FournisseurProvider Noms des en-têtesHeader names
Azure Active DirectoryAzure Active Directory X-MS-TOKEN-AAD-ID-TOKEN
X-MS-TOKEN-AAD-ACCESS-TOKEN
X-MS-TOKEN-AAD-EXPIRES-ON
X-MS-TOKEN-AAD-REFRESH-TOKEN
Jeton FacebookFacebook Token X-MS-TOKEN-FACEBOOK-ACCESS-TOKEN
X-MS-TOKEN-FACEBOOK-EXPIRES-ON
GoogleGoogle X-MS-TOKEN-GOOGLE-ID-TOKEN
X-MS-TOKEN-GOOGLE-ACCESS-TOKEN
X-MS-TOKEN-GOOGLE-EXPIRES-ON
X-MS-TOKEN-GOOGLE-REFRESH-TOKEN
Compte MicrosoftMicrosoft Account X-MS-TOKEN-MICROSOFTACCOUNT-ACCESS-TOKEN
X-MS-TOKEN-MICROSOFTACCOUNT-EXPIRES-ON
X-MS-TOKEN-MICROSOFTACCOUNT-AUTHENTICATION-TOKEN
X-MS-TOKEN-MICROSOFTACCOUNT-REFRESH-TOKEN
TwitterTwitter X-MS-TOKEN-TWITTER-ACCESS-TOKEN
X-MS-TOKEN-TWITTER-ACCESS-TOKEN-SECRET

À partir de votre code client (par exemple, une application mobile ou un navigateur JavaScript), envoyez une requête GET HTTP à /.auth/me.From your client code (such as a mobile app or in-browser JavaScript), send an HTTP GET request to /.auth/me. La réponse JSON retournée contient les jetons spécifiques au fournisseur.The returned JSON has the provider-specific tokens.

Notes

Les jetons d’accès permettent d’accéder aux ressources du fournisseur. Ils ne s’affichent donc que si vous configurez votre fournisseur avec une clé secrète client.Access tokens are for accessing provider resources, so they are present only if you configure your provider with a client secret. Pour savoir comment obtenir des jetons d’actualisation, consultez Actualiser des jetons d’accès.To see how to get refresh tokens, see Refresh access tokens.

Actualiser des jetons de fournisseur d’identitéRefresh identity provider tokens

Lorsque le jeton d'accès de votre fournisseur (et non le jeton de session) expire, vous devez réauthentifier l’utilisateur avant de réutiliser ce jeton.When your provider's access token (not the session token) expires, you need to reauthenticate the user before you use that token again. Vous pouvez éviter l’expiration du jeton en effectuant un appel GET au point de terminaison /.auth/refresh de votre application.You can avoid token expiration by making a GET call to the /.auth/refresh endpoint of your application. Lorsqu’il est appelé, App Service actualise automatiquement les jetons d’accès dans le magasin de jetons pour l’utilisateur authentifié.When called, App Service automatically refreshes the access tokens in the token store for the authenticated user. Les demandes de jeton suivantes effectuées via le code de votre application permettent d’obtenir les jetons actualisés.Subsequent requests for tokens by your app code get the refreshed tokens. Toutefois, pour que l’actualisation des jetons soit effective, le magasin de jetons doit contenir les jetons d’actualisation pour votre fournisseur.However, for token refresh to work, the token store must contain refresh tokens for your provider. La procédure pour obtenir des jetons d’actualisation est fournie par chaque fournisseur. La liste suivante en fournit toutefois un bref résumé :The way to get refresh tokens are documented by each provider, but the following list is a brief summary:

  • Google : ajouter un paramètre de chaîne de requête access_type=offline à votre appel d’API /.auth/login/google.Google: Append an access_type=offline query string parameter to your /.auth/login/google API call. Si vous utilisez le kit de développement logiciel Mobile Apps, vous pouvez ajouter le paramètre à l’une des surcharges LogicAsync (voir Google Refresh Tokens (Jetons d’actualisation Google)).If using the Mobile Apps SDK, you can add the parameter to one of the LogicAsync overloads (see Google Refresh Tokens).
  • Facebook : ne fournit pas de jetons d’actualisation.Facebook: Doesn't provide refresh tokens. Les jetons de longue durée expirent au bout de 60 jours (voir Facebook Expiration and Extension of Access Tokens (Expiration et prolongation des jetons d’accès Facebook)).Long-lived tokens expire in 60 days (see Facebook Expiration and Extension of Access Tokens).
  • Twitter : les jetons d’accès n’expirent pas (voir Twitter OAuth FAQ (FAQ sur l’authentification OAuth Twitter)).Twitter: Access tokens don't expire (see Twitter OAuth FAQ).
  • Compte Microsoft : au moment de configurer les paramètres d’authentification de compte Microsoft, sélectionnez l’étendue wl.offline_access.Microsoft Account: When configuring Microsoft Account Authentication Settings, select the wl.offline_access scope.
  • Azure Active Directory : dans https://resources.azure.com, procédez comme suit :Azure Active Directory: In https://resources.azure.com, do the following steps:
    1. En haut de la page, sélectionnez Lecture/écriture.At the top of the page, select Read/Write.

    2. Dans le navigateur de gauche, accédez à abonnements > <subscription_name > resourceGroups > <resource_group_name> > fournisseurs > Microsoft.Web > sites > <app_name> > config > authsettings.In the left browser, navigate to subscriptions > <subscription_name > resourceGroups > <resource_group_name> > providers > Microsoft.Web > sites > <app_name> > config > authsettings.

    3. Cliquez sur Modifier.Click Edit.

    4. Modifiez la propriété suivante.Modify the following property. Remplacez la valeur <app_id> par l’ID d’application Azure Active Directory du service auquel vous souhaitez accéder.Replace <app_id> with the Azure Active Directory application ID of the service you want to access.

      "additionalLoginParams": ["response_type=code id_token", "resource=<app_id>"]
      
    5. Cliquez sur Put.Click Put.

Une fois que votre fournisseur est configuré, vous pouvez rechercher le jeton d’actualisation et l’heure d’expiration pour le jeton d’accès dans le magasin de jetons.Once your provider is configured, you can find the refresh token and the expiration time for the access token in the token store.

Pour actualiser votre jeton d’accès à tout moment, il vous suffit d’appeler /.auth/refresh dans n’importe quel langage.To refresh your access token at any time, just call /.auth/refresh in any language. L’extrait de code suivant utilise jQuery pour actualiser vos jetons d’accès à partir d’un client JavaScript.The following snippet uses jQuery to refresh your access tokens from a JavaScript client.

function refreshTokens() {
  let refreshUrl = "/.auth/refresh";
  $.ajax(refreshUrl) .done(function() {
    console.log("Token refresh completed successfully.");
  }) .fail(function() {
    console.log("Token refresh failed. See application logs for details.");
  });
}

Si un utilisateur révoque les autorisations accordées à votre application, votre appel à /.auth/me peut échouer avec une réponse 403 Forbidden.If a user revokes the permissions granted to your app, your call to /.auth/me may fail with a 403 Forbidden response. Pour diagnostiquer les erreurs, consultez vos journaux d’activité d’application pour obtenir des informations supplémentaires.To diagnose errors, check your application logs for details.

Étendre la période de grâce d’expiration de jeton de sessionExtend session token expiration grace period

La session authentifiée expire au bout de 8 heures.The authenticated session expires after 8 hours. Après expiration d’une session authentifiée, une période de grâce de 72 heures s’applique par défaut.After an authenticated session expires, there is a 72-hour grace period by default. Au cours de cette période de grâce, vous pouvez actualiser le jeton de session via App Service sans réauthentifier l’utilisateur.Within this grace period, you're allowed to refresh the session token with App Service without reauthenticating the user. Vous pouvez simplement appeler /.auth/refresh lorsque jeton de session n’est plus valide. Vous n’avez pas besoin de vérifier vous-même les dates d’expiration des jetons.You can just call /.auth/refresh when your session token becomes invalid, and you don't need to track token expiration yourself. À la fin de la période de grâce de 72 heures, l’utilisateur doit se connecter à nouveau pour obtenir un jeton de session valide.Once the 72-hour grace period is lapses, the user must sign in again to get a valid session token.

Si le délai de 72 heures n’est pas suffisamment long pour vous, vous pouvez étendre cette fenêtre d’expiration.If 72 hours isn't enough time for you, you can extend this expiration window. Étendre la fenêtre d’expiration sur une longue période peut avoir une incidence majeure sur la sécurité (par exemple lorsqu’un jeton d’authentification est divulgué ou volé).Extending the expiration over a long period could have significant security implications (such as when an authentication token is leaked or stolen). Nous vous recommandons donc de conserver la valeur par défaut de 72 heures ou de définir la période d’extension sur la valeur minimale.So you should leave it at the default 72 hours or set the extension period to the smallest value.

Pour étendre la fenêtre d’expiration par défaut, exécutez la commande suivante dans Cloud Shell.To extend the default expiration window, run the following command in the Cloud Shell.

az webapp auth update --resource-group <group_name> --name <app_name> --token-refresh-extension-hours <hours>

Notes

La période de grâce s’applique uniquement à la session App Service authentifiée, et non aux jetons fournis par les fournisseurs d’identité.The grace period only applies to the App Service authenticated session, not the tokens from the identity providers. Il n’existe aucune période de grâce pour les jetons de fournisseur ayant expiré.There is no grace period for the expired provider tokens.

Restreindre le domaine des comptes de connexionLimit the domain of sign-in accounts

Les options Compte Microsoft et Azure Active Directory permettent de se connecter à partir de multiples domaines.Both Microsoft Account and Azure Active Directory lets you sign in from multiple domains. Par exemple, l’option Compte Microsoft prend en charge les comptes outlook.com, live.com et hotmail.com.For example, Microsoft Account allows outlook.com, live.com, and hotmail.com accounts. Azure Active Directory prend en charge un nombre illimité de domaines personnalisés pour les comptes de connexion.Azure AD allows any number of custom domains for the sign-in accounts. Toutefois, vous pouvez accélérer l’accès de vos utilisateurs directement à votre propre page de connexion Azure AD (par exemple, contoso.com).However, you may want to accelerate your users straight to your own branded Azure AD sign-in page (such as contoso.com). Pour suggérer le nom de domaine des comptes de connexion, procédez comme suit.To suggest the domain name of the sign-in accounts, follow these steps.

Dans https://resources.azure.com, accédez à abonnements > < subscription_ name > resourceGroups > < resource_ group_ name> > fournisseurs > Microsoft.Web > sites > < app_ name> > config > authsettings.In https://resources.azure.com, navigate to subscriptions > <subscription_name > resourceGroups > <resource_group_name> > providers > Microsoft.Web > sites > <app_name> > config > authsettings.

Cliquez sur Modifier, modifiez la propriété suivante, puis cliquez sur Put.Click Edit, modify the following property, and then click Put. Veillez à remplacer la valeur <domain_name> par le domaine souhaité.Be sure to replace <domain_name> with the domain you want.

"additionalLoginParams": ["domain_hint=<domain_name>"]

Ce paramètre ajoute le paramètre de chaîne de requête domain_hint à l’URL de redirection de la connexion.This setting appends the domain_hint query string parameter to the login redirect URL.

Important

Le client peut supprimer le paramètre domain_hint après avoir reçu l’URL de redirection, puis de se connecter avec un autre domaine.It's possible for the client to remove the domain_hint parameter after receiving the redirect URL, and then login with a different domain. Bien que cette fonction soit pratique, il ne s’agit pas d’une fonctionnalité de sécurité.So while this function is convenient, it's not a security feature.

Autoriser ou refuser des utilisateursAuthorize or deny users

Bien que App Service se charge du cas d’autorisation le plus simple (c’est-à-dire le rejet des demandes non authentifiées), votre application peut nécessiter un comportement d’autorisation plus précis, tel que la limitation de l’accès à un groupe spécifique d’utilisateurs.While App Service takes care of the simplest authorization case (i.e. reject unauthenticated requests), your app may require more fine-grained authorization behavior, such as limiting access to only a specific group of users. Dans certains cas, vous devez écrire un code d’application personnalisé pour autoriser ou refuser l’accès à l’utilisateur connecté.In certain cases, you need to write custom application code to allow or deny access to the signed-in user. Dans d’autres cas, App Service ou votre fournisseur d’identité peut être en mesure de vous aider sans modification du code.In other cases, App Service or your identity provider may be able to help without requiring code changes.

Au niveau du serveur (applications Windows uniquement)Server level (Windows apps only)

Pour toute application Windows, vous pouvez définir le comportement d’autorisation du serveur web IIS en modifiant le fichier Web.config.For any Windows app, you can define authorization behavior of the IIS web server, by editing the Web.config file. Les applications Linux n’utilisent pas IIS et ne peuvent pas être configurées à l’aide du fichier Web.config.Linux apps don't use IIS and can't be configured through Web.config.

  1. Accédez à https://<app-name>.scm.azurewebsites.net/DebugConsole.Navigate to https://<app-name>.scm.azurewebsites.net/DebugConsole

  2. Dans l’explorateur de navigateur de vos fichiers App Service, accédez à site/wwwroot.In the browser explorer of your App Service files, navigate to site/wwwroot. S’il n’existe pas de fichier Web.config, créez-en un en sélectionnant + > Nouveau fichier.If a Web.config doesn't exist, create it by selecting + > New File.

  3. Sélectionnez le crayon correspondant à Web. config pour le modifier.Select the pencil for Web.config to edit it. Ajoutez le code de configuration suivant, puis cliquez sur Enregistrer.Add the following configuration code and click Save. Si le fichier Web.config existe, ajoutez simplement l’élément <authorization> avec tout ce qui se trouve dans celui-ci.If Web.config already exists, just add the <authorization> element with everything in it. Ajoutez les comptes que vous souhaitez autoriser dans l’élément <allow>.Add the accounts you want to allow in the <allow> element.

    <?xml version="1.0" encoding="utf-8"?>
    <configuration>
       <system.web>
          <authorization>
            <allow users="user1@contoso.com,user2@contoso.com"/>
            <deny users="*"/>
          </authorization>
       </system.web>
    </configuration>
    

Au niveau du fournisseur d’identitéIdentity provider level

Le fournisseur d’identité peut fournir un autorisation clé en main.The identity provider may provide certain turn-key authorization. Par exemple :For example:

Niveau d’applicationApplication level

Si l’un des autres niveaux ne fournit pas l’autorisation dont vous avez besoin, ou si votre plateforme ou fournisseur d’identité ne sont pas pris en charge, vous devez écrire du code personnalisé afin d’autoriser les utilisateurs en fonction de leurs revendications.If either of the other levels don't provide the authorization you need, or if your platform or identity provider isn't supported, you must write custom code to authorize users based on the user claims.

Étapes suivantesNext steps