Расширенное использование проверки подлинности и авторизации в Службе приложений AzureAdvanced usage of authentication and authorization in Azure App Service

В этой статье показано, как настроить встроенные проверку подлинности и авторизацию в службе приложений, а также управлять удостоверениями, используя приложение.This article shows you how to customize the built-in authentication and authorization in App Service, and to manage identity from your application.

Чтобы быстро приступить к работе, ознакомьтесь с одним из следующих руководств:To get started quickly, see one of the following tutorials:

Использование нескольких поставщиков входаUse multiple sign-in providers

На портале нельзя напрямую настроить несколько поставщиков входа для пользователей (например, через Facebook и 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). Однако эту функцию можно легко добавить к функциональным возможностям вашего приложения.However, it isn't difficult to add the functionality to your app. Для этого необходимо сделать следующее:The steps are outlined as follows:

Во-первых, на странице Authentication / Authorization (Проверка подлинности и авторизация) на портале Azure настройте все поставщики удостоверений, которые нужно включить.First, in the Authentication / Authorization page in the Azure portal, configure each of the identity provider you want to enable.

В раскрывающемся списке Action to take when request is not authenticated (Предпринимаемое действие, если проверка подлинности для запроса не выполнена) выберите Разрешить анонимные запросы (нет действия).In Action to take when request is not authenticated, select Allow Anonymous requests (no action).

На странице входа, на панели навигации или в любом другом расположении приложения добавьте ссылку входа для каждого включенного поставщика (/.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>). Пример: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>

Когда пользователь щелкнет одну из этих ссылок, откроется соответствующая страница для входа.When the user clicks on one of the links, the respective sign-in page opens to sign in the user.

Чтобы перенаправить пользователя после входа по пользовательскому URL-адресу, используйте параметр строки запроса post_login_redirect_url (не следует путать с URI перенаправления в конфигурации поставщика удостоверений).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). Например, чтобы перенаправить пользователя к /Home/Index после входа в систему, используйте следующий код HTML: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>

Проверка токенов от поставщиковValidate tokens from providers

При входе с помощью клиента приложение входит в систему поставщика вручную, а затем отправляет токен проверки подлинности службе приложений для проверки (см. Поток проверки подлинности).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). Эта проверка сама по себе не предоставляет вам доступ к требуемым ресурсам приложения, но успешная проверка даст вам токен сеанса, который вы можете использовать для доступа к ресурсам приложений.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.

Чтобы проверить токен поставщика, для приложения службы приложений сначала нужно настроить требуемый поставщик.To validate the provider token, App Service app must first be configured with the desired provider. Получив токен проверки подлинности у своего поставщика, во время выполнения отправьте токен по адресу /.auth/login/<provider> для проверки.At runtime, after you retrieve the authentication token from your provider, post the token to /.auth/login/<provider> for validation. Пример:For example:

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

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

Формат токена незначительно отличается в соответствии с поставщиком.The token format varies slightly according to the provider. Подробности см. в следующей таблице:See the following table for details:

Значение поставщикаProvider value Требуется в тексте запросаRequired in request body КомментарииComments
aad {"access_token":"<access_token>"}
microsoftaccount {"access_token":"<token>"} Свойство expires_in необязательное.The expires_in property is optional.
При запросе маркера из служб Live всегда запрашиваются области wl.basic.When requesting the token from Live services, always request the wl.basic scope.
google {"id_token":"<id_token>"} Свойство authorization_code необязательное.The authorization_code property is optional. Если указано, при необходимости оно может сопровождаться свойством redirect_uri.When specified, it can also optionally be accompanied by the redirect_uri property.
facebook {"access_token":"<user_access_token>"} Используйте допустимый токен доступа пользователя из Facebook.Use a valid user access token from Facebook.
twitter {"access_token":"<access_token>", "access_token_secret":"<acces_token_secret>"}

При успешной проверке токена поставщика API возвращается с authenticationToken в тексте ответа, который является вашим токеном сеанса.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:..."
    }
}

Получив этот токен сеанса, вы можете получить доступ к защищенным ресурсам приложений, добавив заголовок X-ZUMO-AUTH к HTTP-запросам.Once you have this session token, you can access protected app resources by adding the X-ZUMO-AUTH header to your HTTP requests. Пример:For example:

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

Выход из сеансаSign out of a session

Пользователи могут сделать выход, отправив запрос GET в конечную точку /.auth/logout приложения.Users can initiate a sign-out by sending a GET request to the app's /.auth/logout endpoint. Запрос GET выполняет следующие действия:The GET request does the following:

  • Очищает файлы cookie проверки подлинности в текущем сеансе.Clears authentication cookies from the current session.
  • Удаляет текущие маркеры пользователя из хранилища маркеров.Deletes the current user's tokens from the token store.
  • Выполняет выход в поставщике удостоверений на стороне сервера для Azure Active Directory и Google.For Azure Active Directory and Google, performs a server-side sign-out on the identity provider.

Здесь представлена ссылка для простого выхода на веб-странице:Here's a simple sign-out link in a webpage:

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

После успешного выхода клиент по умолчанию перенаправляется на URL-адрес /.auth/logout/done.By default, a successful sign-out redirects the client to the URL /.auth/logout/done. Можно изменить страницу перенаправления после выхода, добавив параметр запроса post_logout_redirect_uri.You can change the post-sign-out redirect page by adding the post_logout_redirect_uri query parameter. Пример:For example:

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

Рекомендуется закодировать значение post_logout_redirect_uri.It's recommended that you encode the value of post_logout_redirect_uri.

При использовании полного URL-адреса он должен размещаться в одном и том же домене или быть настроенным в качестве разрешенного URL-адреса внешнего перенаправления для приложения.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. В следующем примере показано перенаправление на адрес https://myexternalurl.com, который не размещен в одном и том же домене: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

Выполните следующую команду в 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"

Сохранение фрагментов URL-адресаPreserve URL fragments

После входа в приложение пользователи обычно желают быть перенаправленными в один и тот же раздел той же страницы, например /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. Но так как фрагменты URL-адреса (например, #SectionZ) никогда не отправляются на сервер, они не сохраняются по умолчанию после завершения входа OAuth и перенаправления обратно в приложение.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. Это неудобно для пользователей, когда им снова нужно перейти в требуемую закладку.Users then get a suboptimal experience when they need to navigate to the desired anchor again. Это ограничение распространяется на все решения аутентификации на стороне сервера.This limitation applies to all server-side authentication solutions.

При использовании аутентификации службы приложений можно сохранять фрагменты URL-адресов во время входа OAuth.In App Service authentication, you can preserve URL fragments across the OAuth sign-in. Чтобы сделать это, установите для параметра приложения WEBSITE_AUTH_PRESERVE_URL_FRAGMENT значение true.To do this, set an app setting called WEBSITE_AUTH_PRESERVE_URL_FRAGMENT to true. Это можно сделать на портале Azure или просто выполнив следующую команду в 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"

Доступ к утверждениям пользователейAccess user claims

Служба приложений передает утверждения пользователей в приложение с помощью специальных заголовков.App Service passes user claims to your application by using special headers. Эти заголовки нельзя настроить с помощью внешних запросов. Они присутствуют, только если это установлено службой приложений.External requests aren't allowed to set these headers, so they are present only if set by App Service. Некоторые примеры заголовков включают:Some example headers include:

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

Сведения из этих заголовков можно получить с помощью кода, написанного на любом языке или в любой платформе.Code that is written in any language or framework can get the information that it needs from these headers. Для приложений ASP.NET 4.6 автоматически настраивается класс ClaimsPrincipal с соответствующими значениями.For ASP.NET 4.6 apps, the ClaimsPrincipal is automatically set with the appropriate values. Однако ASP.NET Core не предоставляет по промежуточного слоя для проверки подлинности, которое интегрируется с утверждениями пользователя службы приложений.ASP.NET Core, however, doesn't provide an authentication middleware that integrates with App Service user claims. Обходной путь см. в разделе максимерауиллер. Azure. AppService. еасяус.For a workaround, see MaximeRouiller.Azure.AppService.EasyAuth.

Если хранилище токенов включено для приложения, можно также получить дополнительные сведения о прошедшем проверку подлинности пользователе, вызвав метод /.auth/me .If the token store is enabled for your app, you can also obtain additional details on the authenticated user by calling /.auth/me. Пакеты SDK для серверной части мобильных приложений предоставляют вспомогательные методы для работы с этими данными Дополнительные сведения см.The Mobile Apps server SDKs provide helper methods to work with this data. Дополнительные сведения см. в разделах Практическое руководство. Использование утверждений аутентификации для таблиц и Практическое руководство. Получение сведений о пользователе, прошедшем проверку подлинности.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.

Извлечение токенов в коде приложенияRetrieve tokens in app code

Токены, предоставляющиеся поставщиком, вводятся в заголовке запроса из кода сервера, что позволяет легко получить к ним доступ.From your server code, the provider-specific tokens are injected into the request header, so you can easily access them. В следующей таблице показаны возможные заголовки токена.The following table shows possible token header names:

ПоставщикProvider Имена заголовковHeader 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
Токен 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
Учетная запись МайкрософтMicrosoft 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

В коде клиента (например, в мобильном приложении или в браузере JavaScript) отправьте 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 (token store must be enabled). В возвращаемом JSON-файле будут содержаться предоставляемые поставщиком токены.The returned JSON has the provider-specific tokens.

Примечание

Токены доступа предназначены для получения доступа к ресурсам поставщика, поэтому они заданы, только если настройка поставщика осуществляется с помощью секрета клиента.Access tokens are for accessing provider resources, so they are present only if you configure your provider with a client secret. Дополнительные сведения о том, как получить токены обновления, см. в разделе об обновлении маркеров доступа.To see how to get refresh tokens, see Refresh access tokens.

Обновление маркеров поставщика удостоверенийRefresh identity provider tokens

По истечении срока действия маркера доступа вашего провайдера (а не токена сеанса) необходимо повторно подтвердить подлинность пользователя, прежде чем снова использовать этот маркер.When your provider's access token (not the session token) expires, you need to reauthenticate the user before you use that token again. Истечения срока действия токена можно избежать, выполнив вызов GET к конечной точке приложения /.auth/refresh.You can avoid token expiration by making a GET call to the /.auth/refresh endpoint of your application. При вызове служба приложений автоматически обновляет маркеры доступа в хранилище токенов для пользователя, прошедшего проверку подлинности.When called, App Service automatically refreshes the access tokens in the token store for the authenticated user. В результате последующих запросов на токены с помощью кода приложения будут возвращаться обновленные токены.Subsequent requests for tokens by your app code get the refreshed tokens. Однако для правильного обновления токена в хранилище токенов должны содержаться токены обновления для поставщика.However, for token refresh to work, the token store must contain refresh tokens for your provider. Способ получения токенов обновления документируется каждым поставщиком, но ниже приведено краткое описание.The way to get refresh tokens are documented by each provider, but the following list is a brief summary:

  • Google. Добавьте параметр строки запроса access_type=offline к вызову API /.auth/login/google.Google: Append an access_type=offline query string parameter to your /.auth/login/google API call. Если используется пакет SDK для мобильных служб, можно добавить параметр к одной из перегрузок LogicAsync (см. в разделе о токенах обновления Google).If using the Mobile Apps SDK, you can add the parameter to one of the LogicAsync overloads (see Google Refresh Tokens).
  • Facebook. Не предоставляет токены обновления.Facebook: Doesn't provide refresh tokens. Срок действия токенов с долгим временем существования истекает через 60 дней (см. раздел об истечении и продлении срока действия токенов доступа Facebook).Long-lived tokens expire in 60 days (see Facebook Expiration and Extension of Access Tokens).
  • Twitter. Срок действия токенов доступа не истекает (см. раздел о часто задаваемых вопросах о Twitter OAuth).Twitter: Access tokens don't expire (see Twitter OAuth FAQ).
  • Учетная запись Майкрософт. Настраивая параметры проверки подлинности учетной записи Майкрософт, выберите область wl.offline_access.Microsoft Account: When configuring Microsoft Account Authentication Settings, select the wl.offline_access scope.
  • Azure Active Directory. В https://resources.azure.com сделайте следующее:Azure Active Directory: In https://resources.azure.com, do the following steps:
    1. В верхней части страницы выберите Read/Write (Чтение и запись).At the top of the page, select Read/Write.

    2. В левом браузере перейдите к разделу подписки > * *_ <subscription_name_** > resourceGroups > * _ * <resource_group_name> _ поставщики> > 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. Нажмите кнопку Изменить.Click Edit.

    4. Измените следующее свойство.Modify the following property. Замените <app_id> Azure Active Directory идентификатором приложения службы, к которой требуется получить доступ.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. Щелкните Put.Click Put.

После настройки поставщика можно найти токен обновления и срок действия для токена доступа в хранилище токенов.Once your provider is configured, you can find the refresh token and the expiration time for the access token in the token store.

Чтобы обновить маркер доступа в любое время, просто вызовите /.auth/refresh его на любом языке.To refresh your access token at any time, just call /.auth/refresh in any language. В следующем фрагменте кода jQuery используется для обновления токенов доступа из клиента 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.");
  });
}

Если пользователь отменяет разрешения, предоставленные приложению, вызов /.auth/me может завершиться ошибкой 403 Forbidden.If a user revokes the permissions granted to your app, your call to /.auth/me may fail with a 403 Forbidden response. Чтобы выполнить диагностику ошибок, проверьте дополнительные сведения в журналах приложений.To diagnose errors, check your application logs for details.

Продление льготного периода срока действия токена сеансаExtend session token expiration grace period

Сеанс проверки подлинности истекает через 8 часов.The authenticated session expires after 8 hours. По истечении срока действия авторизованного сеанса по умолчанию предоставляется 72-часовой льготный период.After an authenticated session expires, there is a 72-hour grace period by default. В течение этого льготного периода токен сеанса можно обновить с помощью Службы приложений без повторной проверки подлинности пользователя.Within this grace period, you're allowed to refresh the session token with App Service without reauthenticating the user. Если токен сеанса становится недействительным, вы можете просто вызвать /.auth/refresh, и вам не нужно самостоятельно отслеживать истечение срока действия токена.You can just call /.auth/refresh when your session token becomes invalid, and you don't need to track token expiration yourself. После завершения 72-часового льготного периода пользователь должен выполнить вход в систему, чтобы получить действительный токен сеанса.Once the 72-hour grace period is lapses, the user must sign in again to get a valid session token.

Если 72 часов не достаточно, можно продлить этот льготный период.If 72 hours isn't enough time for you, you can extend this expiration window. Значительное продление этого периода может повлиять на уровень безопасности (например, токен проверки подлинности может быть утерян или украден).Extending the expiration over a long period could have significant security implications (such as when an authentication token is leaked or stolen). В связи с этим следует оставить значение по умолчанию (72 часа) или установить для периода продления наименьшее значение.So you should leave it at the default 72 hours or set the extension period to the smallest value.

Чтобы продлить льготный период истечения срока действия по умолчанию, выполните следующую команду в 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>

Примечание

Льготный период применяется только к сеансу, проверка подлинности для которого осуществлялась с помощью службы приложений, а не токенов, предоставляемых поставщиками удостоверений.The grace period only applies to the App Service authenticated session, not the tokens from the identity providers. Льготный период на предоставленные поставщиком токены, срок действия которых истек, не распространяется.There is no grace period for the expired provider tokens.

Ограничение домена учетных записей для входаLimit the domain of sign-in accounts

Учетные записи Майкрософт и Azure Active Directory позволяют выполнять вход из нескольких доменов.Both Microsoft Account and Azure Active Directory lets you sign in from multiple domains. Например, учетная запись Майкрософт позволяет выполнять вход с помощью учетных записей outlook.com, live.com и hotmail.com.For example, Microsoft Account allows outlook.com, live.com, and hotmail.com accounts. Azure AD позволяет любому числу пользовательских доменов для учетных записей входа.Azure AD allows any number of custom domains for the sign-in accounts. Тем не менее, вам может потребоваться ускорить работу пользователей с собственной фирменной страницей входа в Azure AD (например, contoso.com ).However, you may want to accelerate your users straight to your own branded Azure AD sign-in page (such as contoso.com). Чтобы предложить доменное имя учетных записей входа, выполните следующие действия.To suggest the domain name of the sign-in accounts, follow these steps.

В https://resources.azure.com перейдите к разделу подписки > * *_ <subscription_name_** > resourceGroups > * _ * <resource_group_name> _ поставщики> > 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.

Щелкните Edit (Изменить), измените следующее свойство и выберите Put.Click Edit, modify the following property, and then click Put. Не забудьте заменить <domain_name> требуемым доменом.Be sure to replace <domain_name> with the domain you want.

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

Этот параметр добавляет domain_hint параметр строки запроса к URL-адресу перенаправления имени входа.This setting appends the domain_hint query string parameter to the login redirect URL.

Важно!

Клиент может удалить domain_hint параметр после получения URL-адреса перенаправления, а затем войти в другой домен.It's possible for the client to remove the domain_hint parameter after receiving the redirect URL, and then login with a different domain. Поэтому хотя эта функция удобна, она не является функцией безопасности.So while this function is convenient, it's not a security feature.

Авторизовать или запретить пользователейAuthorize or deny users

Хотя служба приложений отвечает за простейший вариант авторизации (т. е. отклонять запросы без проверки подлинности), приложение может потребовать более детального поведения авторизации, например ограничение доступа только к определенной группе пользователей.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. В некоторых случаях необходимо написать пользовательский код приложения, чтобы разрешить или запретить доступ для пользователя, выполнившего вход.In certain cases, you need to write custom application code to allow or deny access to the signed-in user. В других случаях служба приложений или поставщик удостоверений могут помочь без внесения изменений в код.In other cases, App Service or your identity provider may be able to help without requiring code changes.

Уровень сервера (только для приложений Windows)Server level (Windows apps only)

Для любого приложения Windows можно определить поведение авторизации веб-сервера IIS, изменив файл Web.config .For any Windows app, you can define authorization behavior of the IIS web server, by editing the Web.config file. Приложения Linux не используют IIS и не могут быть настроены с помощью Web.config.Linux apps don't use IIS and can't be configured through Web.config.

  1. Перейдите на страницу https://<app-name>.scm.azurewebsites.net/DebugConsole.Navigate to https://<app-name>.scm.azurewebsites.net/DebugConsole

  2. В обозревателе браузера файлов службы приложений перейдите на сайт Site/wwwroot.In the browser explorer of your App Service files, navigate to site/wwwroot. Если Web.config не существует, создайте его, выбрав + > создать файл.If a Web.config doesn't exist, create it by selecting + > New File.

  3. Выберите карандаш для Web.config , чтобы изменить его.Select the pencil for Web.config to edit it. Добавьте следующий код конфигурации и нажмите кнопку сохранить.Add the following configuration code and click Save. Если Web.config уже существует, просто добавьте <authorization> элемент со всеми элементами.If Web.config already exists, just add the <authorization> element with everything in it. Добавьте учетные записи, которые требуется разрешить, в <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>
    

Уровень поставщика удостоверенийIdentity provider level

Поставщик удостоверений может предоставить некоторую проверку подлинности с помощью ключа.The identity provider may provide certain turn-key authorization. Пример:For example:

На уровне приложенияApplication level

Если любой из других уровней не обеспечивает необходимую авторизацию или если ваша платформа или поставщик удостоверений не поддерживается, необходимо написать пользовательский код для авторизации пользователей на основе утверждений пользователей.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.

Настройка с помощью файла (Предварительная версия) Configure using a file (preview)

При необходимости можно настроить параметры проверки подлинности с помощью файла, предоставленного вашим развертыванием.Your auth settings can optionally be configured via a file that is provided by your deployment. Это может потребоваться для некоторых возможностей предварительной версии проверки подлинности и авторизации службы приложений.This may be required by certain preview capabilities of App Service Authentication / Authorization.

Важно!

Помните, что полезные данные приложения и, следовательно, могут перемещаться между средами, как и с слотами.Remember that your app payload, and therefore this file, may move between environments, as with slots. Вполне вероятно, что для каждого слота будет закреплена другая регистрация приложения, и в таких случаях следует продолжить использовать стандартный метод настройки вместо использования файла конфигурации.It is likely you would want a different app registration pinned to each slot, and in these cases, you should continue to use the standard configuration method instead of using the configuration file.

Включение конфигурации на основе файловEnabling file-based configuration

Внимание!

Во время предварительной версии включение настройки на основе файлов приведет к отключению управления функцией проверки подлинности и авторизации службы приложений с помощью некоторых клиентов, таких как портал Azure, Azure CLI и Azure PowerShell.During preview, enabling file-based configuration will disable management of the App Service Authentication / Authorization feature for your application through some clients, such as the Azure portal, Azure CLI, and Azure PowerShell.

  1. Создайте новый JSON-файл для конфигурации в корне проекта (развернутый в D:\home\site\wwwroot в приложении для Интернета или функции).Create a new JSON file for your configuration at the root of your project (deployed to D:\home\site\wwwroot in your web / function app). Укажите требуемую конфигурацию в соответствии с файловой ссылкой на файловую конфигурацию.Fill in your desired configuration according to the file-based configuration reference. При изменении существующей конфигурации Azure Resource Manager убедитесь, что свойства, захваченные в коллекции, переведены в authsettings файл конфигурации.If modifying an existing Azure Resource Manager configuration, make sure to translate the properties captured in the authsettings collection into your configuration file.

  2. Измените существующую конфигурацию, которая захватывается в Azure Resource Manager API в разделе Microsoft.Web/sites/<siteName>/config/authsettings .Modify the existing configuration, which is captured in the Azure Resource Manager APIs under Microsoft.Web/sites/<siteName>/config/authsettings. Чтобы изменить это, можно использовать шаблон Azure Resource Manager или средство, например Обозреватель ресурсов Azure.To modify this, you can use an Azure Resource Manager template or a tool like Azure Resource Explorer. В коллекции authsettings необходимо задать три свойства (и, возможно, удалить другие):Within the authsettings collection, you will need to set three properties (and may remove others):

    1. Значение enabled "true"Set enabled to "true"
    2. Значение isAuthFromFile "true"Set isAuthFromFile to "true"
    3. Задайте authFilePath в качестве имени файла (например, "auth.js").Set authFilePath to the name of the file (for example, "auth.json")

Примечание

Формат authFilePath различается для разных платформ.The format for authFilePath varies between platforms. В Windows поддерживаются как относительные, так и абсолютные пути.On Windows, both relative and absolute paths are supported. Рекомендуется использовать относительный вариант.Relative is recommended. В Linux в настоящее время поддерживаются только абсолютные пути, поэтому значение параметра должно быть "/Хоме/Сите/ввврут/auth.json" или аналогичным образом.For Linux, only absolute paths are supported currently, so the value of the setting should be "/home/site/wwwroot/auth.json" or similar.

После внесения этого обновления конфигурации содержимое файла будет использоваться для определения поведения проверки подлинности и авторизации службы приложений для этого сайта.Once you have made this configuration update, the contents of the file will be used to define the behavior of App Service Authentication / Authorization for that site. Если вы хотите вернуться к Azure Resource Managerной конфигурации, это можно сделать, задав значение isAuthFromFile "false".If you ever wish to return to Azure Resource Manager configuration, you can do so by setting isAuthFromFile back to "false".

Ссылка на файл конфигурацииConfiguration file reference

Все секреты, на которые будет ссылаться файл конфигурации, должны храниться в виде параметров приложения.Any secrets that will be referenced from your configuration file must be stored as application settings. Вы можете назвать все нужные параметры.You may name the settings anything you wish. Просто убедитесь, что ссылки из файла конфигурации используют одни и те же ключи.Just make sure that the references from the configuration file uses the same keys.

Ниже перечислены возможные варианты конфигурации в файле.The following exhausts possible configuration options within the file:

{
    "platform": {
        "enabled": <true|false>
    },
    "globalValidation": {
        "requireAuthentication": <true|false>,
        "unauthenticatedClientAction": "RedirectToLoginPage|AllowAnonymous|Return401|Return403",
        "redirectToProvider": "<default provider alias>",
        "excludedPaths": [
            "/path1",
            "/path2"
        ]
    },
    "identityProviders": {
        "azureActiveDirectory": {
            "enabled": <true|false>,
            "registration": {
                "openIdIssuer": "<issuer url>",
                "clientId": "<app id>",
                "clientSecretSettingName": "APP_SETTING_CONTAINING_AAD_SECRET",
            },
            "login": {
                "loginParameters": [
                    "paramName1=value1",
                    "paramName2=value2"
                ]
            },
            "validation": {
                "allowedAudiences": [
                    "audience1",
                    "audience2"
                ]
            }
        },
        "facebook": {
            "enabled": <true|false>,
            "registration": {
                "appId": "<app id>",
                "appSecretSettingName": "APP_SETTING_CONTAINING_FACEBOOK_SECRET"
            },
            "graphApiVersion": "v3.3",
            "login": {
                "scopes": [
                    "profile",
                    "email"
                ]
            },
        },
        "gitHub": {
            "enabled": <true|false>,
            "registration": {
                "clientId": "<client id>",
                "clientSecretSettingName": "APP_SETTING_CONTAINING_GITHUB_SECRET"
            },
            "login": {
                "scopes": [
                    "profile",
                    "email"
                ]
            }
        },
        "google": {
            "enabled": true,
            "registration": {
                "clientId": "<client id>",
                "clientSecretSettingName": "APP_SETTING_CONTAINING_GOOGLE_SECRET"
            },
            "login": {
                "scopes": [
                    "profile",
                    "email"
                ]
            },
            "validation": {
                "allowedAudiences": [
                    "audience1",
                    "audience2"
                ]
            }
        },
        "twitter": {
            "enabled": <true|false>,
            "registration": {
                "consumerKey": "<consumer key>",
                "consumerSecretSettingName": "APP_SETTING_CONTAINING TWITTER_CONSUMER_SECRET"
            }
        },
        "openIdConnectProviders": {
            "provider name": {
                "enabled": <true|false>,
                "registration": {
                    "clientId": "<client id>",
                    "clientCredential": {
                        "secretSettingName": "<name of app setting containing client secret>"
                    },
                    "openIdConnectConfiguration": {
                        "authorizationEndpoint": "<url specifying authorization endpoint>",
                        "tokenEndpoint": "<url specifying token endpoint>",
                        "issuer": "<url specifying issuer>",
                        "certificationUri": "<url specifying jwks endpoint>",
                        "wellKnownOpenIdConfiguration": "<url specifying .well-known/open-id-configuration endpoint - if this property is set, the other properties of this object are ignored, and authorizationEndpoint, tokenEndpoint, issuer, and certificationUri are set to the corresponding values listed at this endpoint>"
                    }
                },
                "login": {
                    "nameClaimType": "<name of claim containing name>",
                    "scope": [
                        "openid",
                        "profile",
                        "email"
                    ],
                    "loginParameterNames": [
                        "paramName1=value1",
                        "paramName2=value2"
                    ],
                }
            },
            //...
        },
        "login": {
            "routes": {
                "logoutEndpoint": "<logout endpoint>"
            },
            "tokenStore": {
                "enabled": <true|false>,
                "tokenRefreshExtensionHours": "<double>",
                "fileSystem": {
                    "directory": "<directory to store the tokens in if using a file system token store (default)>"
                },
                "azureBlobStorage": {
                    "sasUrlSettingName": "<app setting name containing the sas url for the Azure Blob Storage if opting to use that for a token store>"
                }
            },
            "preserveUrlFragmentsForLogins": <true|false>,
            "allowedExternalRedirectUri": [
                "https://uri1.azurewebsites.net/",
                "https://uri2.azurewebsites.net/"
            ],
            "cookieExpiration": {
                "convention": "FixedTime|IdentityProviderDerived",
                "timeToExpiration": "<timespan>"
            },
            "nonce": {
                "validateNonce": <true|false>,
                "nonceExpirationInterval": "<timespan>"
            }
        },
        "httpSettings": {
            "requireHttps": <true|false>,
            "routes": {
                "apiPrefix": "<api prefix>"
            },
            "forwardProxy": {
                "convention": "NoProxy|Standard|Custom",
                "customHostHeaderName": "<host header value>",
                "customProtoHeaderName": "<proto header value>"
            }
        }
    }
}

Закрепление приложения для конкретной версии среды выполнения проверки подлинностиPin your app to a specific authentication runtime version

При включении проверки подлинности и авторизации по промежуточного слоя платформы внедряется в конвейер HTTP-запросов, как описано в обзоре функций.When you enable Authentication / Authorization, platform middleware is injected into your HTTP request pipeline as described in the feature overview. Это по промежуточного слоя платформы периодически обновляется новыми функциями и улучшениями в рамках регулярных обновлений платформы.This platform middleware is periodically updated with new features and improvements as part of routine platform updates. По умолчанию приложение веб-приложения или функции будет выполняться в последней версии этого по промежуточного слоя платформы.By default, your web or function app will run on the latest version of this platform middleware. Эти автоматические обновления всегда имеют обратную совместимость.These automatic updates are always backwards compatible. Однако в редких случаях, когда это автоматическое обновление вводит ошибку во время выполнения для веб-приложения или функции, можно временно вернуться к предыдущей версии по промежуточного слоя.However, in the rare event that this automatic update introduces a runtime issue for your web or function app, you can temporarily roll back to the previous middleware version. В этой статье объясняется, как временно закрепить приложение для определенной версии по промежуточного слоя проверки подлинности.This article explains how to temporarily pin an app to a specific version of the authentication middleware.

Обновление версий автоматически и вручнуюAutomatic and manual version updates

Вы можете закрепить приложение на конкретной версии по промежуточного слоя платформы, задав runtimeVersion параметр для приложения.You can pin your app to a specific version of the platform middleware by setting a runtimeVersion setting for the app. Приложение всегда работает в последней версии, если вы не решили явно закрепить его к определенной версии.Your app always runs on the latest version unless you choose to explicitly pin it back to a specific version. В каждый момент времени будет поддерживаться несколько версий.There will be a few versions supported at a time. Если вы закрепляетесь на недопустимую версию, которая больше не поддерживается, приложение будет использовать последнюю версию.If you pin to an invalid version that is no longer supported, your app will use the latest version instead. Чтобы всегда запускать последнюю версию, задайте значение runtimeVersion ~ 1.To always run the latest version, set runtimeVersion to ~1.

Просмотр и обновление текущей версии среды выполненияView and update the current runtime version

Вы можете изменить версию среды выполнения, используемую приложением.You can change the runtime version used by your app. Новая версия среды выполнения должна вступить в силу после перезапуска приложения.The new runtime version should take effect after restarting the app.

Просмотр текущей версии среды выполненияView the current runtime version

Текущую версию промежуточного слоя проверки подлинности платформы можно просмотреть либо с помощью Azure CLI, либо с помощью одной из конечных точек HTTP built0 версии в приложении.You can view the current version of the platform authentication middleware either using the Azure CLI or via one of the built0-in version HTTP endpoints in your app.

Использование Azure CLIFrom the Azure CLI

С помощью Azure CLI просмотрите текущую версию по промежуточного слоя с помощью команды AZ webapp auth Показать .Using the Azure CLI, view the current middleware version with the az webapp auth show command.

az webapp auth show --name <my_app_name> \
--resource-group <my_resource_group>

В этом коде замените <my_app_name> именем своего приложения.In this code, replace <my_app_name> with the name of your app. Также замените <my_resource_group> именем группы ресурсов для приложения.Also replace <my_resource_group> with the name of the resource group for your app.

Вы увидите runtimeVersion поле в выходных данных CLI.You will see the runtimeVersion field in the CLI output. Он будет похож на следующий пример выходных данных, который был усечен для ясности:It will resemble the following example output, which has been truncated for clarity:

{
  "additionalLoginParams": null,
  "allowedAudiences": null,
    ...
  "runtimeVersion": "1.3.2",
    ...
}
Из конечной точки версииFrom the version endpoint

Также можно нажать конечную точку/.АУС/версион в приложении, чтобы просмотреть текущую версию по промежуточного слоя, в которой выполняется приложение.You can also hit /.auth/version endpoint on an app also to view the current middleware version that the app is running on. Он будет выглядеть примерно следующим образом:It will resemble the following example output:

{
"version": "1.3.2"
}

Обновление текущей версии среды выполненияUpdate the current runtime version

С помощью Azure CLI можно обновить runtimeVersion параметр в приложении с помощью команды AZ webapp auth Update .Using the Azure CLI, you can update the runtimeVersion setting in the app with the az webapp auth update command.

az webapp auth update --name <my_app_name> \
--resource-group <my_resource_group> \
--runtime-version <version>

Замените <my_app_name> именем своего приложения.Replace <my_app_name> with the name of your app. Также замените <my_resource_group> именем группы ресурсов для приложения.Also replace <my_resource_group> with the name of the resource group for your app. Кроме того, замените на <version> допустимую версию среды выполнения 1. x или ~1 для последней версии.Also, replace <version> with a valid version of the 1.x runtime or ~1 for the latest version. Заметки о выпуске можно найти в разных версиях среды выполнения [здесь] ( https://github.com/Azure/app-service-announcements) чтобы определить версию для закрепления.You can find the release notes on the different runtime versions [here] (https://github.com/Azure/app-service-announcements) to help determine the version to pin to.

Эту команду можно выполнить в Azure Cloud Shell, выбрав Попробовать в предыдущем примере кода.You can run this command from the Azure Cloud Shell by choosing Try it in the preceding code sample. Также можно использовать Azure CLI локально для выполнения этой команды после выполнения команды az login для входа.You can also use the Azure CLI locally to execute this command after executing az login to sign in.

Дальнейшие действияNext steps