Проверка подлинности и авторизация в службе приложений Azure и функциях AzureAuthentication and authorization in Azure App Service and Azure Functions

Служба приложений Azure предоставляет встроенные возможности проверки подлинности и авторизации (иногда называется "простой проверкой подлинности"), поэтому вы можете входить в систему пользователей и получать доступ к данным, записывая в веб-приложение, API RESTful и серверной части мобильных приложений минимальный код или нет, а также функции Azure.Azure App Service provides built-in authentication and authorization capabilities (sometimes referred to as "Easy Auth"), so you can sign in users and access data by writing minimal or no code in your web app, RESTful API, and mobile back end, and also Azure Functions. В этой статье описывается, как служба приложений помогает упростить проверку подлинности и авторизацию для вашего приложения.This article describes how App Service helps simplify authentication and authorization for your app.

Зачем использовать встроенную проверку подлинности?Why use the built-in authentication?

Для проверки подлинности и авторизации не требуется использовать эту функцию.You're not required to use this feature for authentication and authorization. Вы можете использовать объединенные функции безопасности в вашей веб-среде или написать собственные служебные программы.You can use the bundled security features in your web framework of choice, or you can write your own utilities. Однако необходимо обеспечить актуальность вашего решения с помощью последних обновлений безопасности, протокола и браузера.However, you will need to ensure that your solution stays up to date with the latest security, protocol, and browser updates.

Реализация безопасного решения для проверки подлинности (пользователей входа) и авторизации (предоставление доступа к защищенным данным) может потребовать значительных усилий.Implementing a secure solution for authentication (signing-in users) and authorization (providing access to secure data) can take significant effort. Необходимо следовать рекомендациям и стандартам отрасли и обеспечить актуальность вашей реализации.You must make sure to follow industry best practices and standards, and keep your implementation up to date. Встроенная функция проверки подлинности для службы приложений и функций Azure позволяет экономить время и усилия, предоставляя встроенную проверку подлинности с помощью федеративных поставщиков удостоверений, что позволяет сосредоточиться на остальной части вашего приложения.The built-in authentication feature for App Service and Azure Functions can save you time and effort by providing out-of-the-box authentication with federated identity providers, allowing you to focus on the rest of your application.

  • Служба приложений Azure позволяет интегрировать различные возможности проверки подлинности в веб-приложение или API, не реализуя их самостоятельно.Azure App Service allows you to integrate a variety of auth capabilities into your web app or API without implementing them yourself.
  • Она встроена непосредственно в платформу и не требует какого бы то ни было конкретного языка, пакета SDK, знаний по безопасности или даже любого кода для использования.It’s built directly into the platform and doesn’t require any particular language, SDK, security expertise, or even any code to utilize.
  • Можно выполнить интеграцию с несколькими поставщиками входа в систему.You can integrate with multiple login providers. Например, Azure AD, Facebook, Google, Twitter.For example, Azure AD, Facebook, Google, Twitter.

Поставщики удостоверенийIdentity providers

Служба приложений использует федеративную идентификацию, при которой сторонний поставщик управляет удостоверениями пользователей и потоком проверки подлинности.App Service uses federated identity, in which a third-party identity provider manages the user identities and authentication flow for you. По умолчанию доступны следующие поставщики удостоверений.The following identity providers are available by default:

ПоставщикProvider Конечная точка входаSign-in endpoint Руководство по How-ToHow-To guidance
Azure Active DirectoryAzure Active Directory /.auth/login/aad Имя входа в службу приложений Azure ADApp Service Azure AD login
Учетная запись МайкрософтMicrosoft Account /.auth/login/microsoftaccount Вход в учетную запись Майкрософт для службы приложенийApp Service Microsoft Account login
FacebookFacebook /.auth/login/facebook Имя входа в Facebook службы приложенийApp Service Facebook login
GoogleGoogle /.auth/login/google Имя входа Google службы приложенийApp Service Google login
TwitterTwitter /.auth/login/twitter Имя входа в Twitter службы приложенийApp Service Twitter login
Любой поставщик OpenID Connect Connect (Предварительная версия)Any OpenID Connect provider (preview) /.auth/login/<providerName> Имя входа для подключения к службе приложений OpenID ConnectApp Service OpenID Connect login

При включении проверки подлинности и авторизации с помощью одного из этих поставщиков конечная точка входа станет доступной для проверки подлинности пользователя и для проверки токенов проверки подлинности от поставщика.When you enable authentication and authorization with one of these providers, its sign-in endpoint is available for user authentication and for validation of authentication tokens from the provider. Вы можете предоставить пользователям любое количество параметров входа.You can provide your users with any number of these sign-in options.

Рекомендации по использованию встроенной проверки подлинностиConsiderations for using built-in authentication

Включение этой функции приведет к автоматическому перенаправлению всех запросов к приложению по протоколу HTTPS независимо от параметра конфигурации службы приложений для принудительного применения HTTPS.Enabling this feature will cause all requests to your application to be automatically redirected to HTTPS, regardless of the App Service configuration setting to enforce HTTPS. Это можно отключить с помощью  requireHttps параметра в конфигурации v2.You can disable this with the  requireHttps setting in the V2 configuration. Однако мы рекомендуем придерживаться протокола HTTPS, и вы должны убедиться, что маркеры безопасности не передаются через небезопасные подключения HTTP.However, we do recommend sticking with HTTPS, and you should ensure no security tokens ever get transmitted over non-secure HTTP connections.

Службу приложений можно использовать для проверки подлинности с помощью или без ограничения доступа к содержимому и API сайта.App Service can be used for authentication with or without restricting access to your site content and APIs. Чтобы ограничить доступ приложений только для пользователей, прошедших проверку подлинности, задайте действие, которое будет выполняться, если запрос не прошел проверку подлинности для входа с помощью одного из настроенных поставщиков удостоверений.To restrict app access only to authenticated users, set Action to take when request is not authenticated to  log in with one of the configured identity providers. Чтобы выполнить проверку подлинности, но не ограничивать доступ, задайте действие, которое будет выполняться, если запрос не прошел проверку подлинности в "разрешить анонимные запросы (без действий)".To authenticate but not restrict access, set Action to take when request is not authenticated to "Allow anonymous requests (no action)."

Примечание

Каждому приложению следует присвоить свое разрешение и согласие.You should give each app registration its own permission and consent. Создайте отдельные регистрации приложений для отдельных слотов развертывания, чтобы не предоставлять общий доступ к разрешениям в средах.Avoid permission sharing between environments by using separate app registrations for separate deployment slots. Это поможет предотвратить проблемы с рабочим приложением при тестировании нового кода.When testing new code, this practice can help prevent issues from affecting the production app.

Принцип работыHow it works

Архитектура функций в Windows (без развертывания контейнера))Feature architecture on Windows (non-container deployment))

Архитектура функций в Linux и контейнерахFeature architecture on Linux and containers

Поток проверки подлинностиAuthentication flow

Поведение авторизацииAuthorization behavior

Утверждения пользователей и приложенийUser and Application claims

Хранилище токеновToken store

Ведение журнала и трассировкаLogging and tracing

Архитектура функций в Windows (без развертывания контейнера)Feature architecture on Windows (non-container deployment)

Модуль проверки подлинности и авторизации выполняется в той же песочнице, что и код приложения.The authentication and authorization module runs in the same sandbox as your application code. Если он включен, каждый входящий HTTP-запрос проходит через него перед обработкой кодом вашего приложения.When it's enabled, every incoming HTTP request passes through it before being handled by your application code.

Схема архитектуры, показывающая запросы, перехваченные процессом в песочнице сайта, который взаимодействует с поставщиками удостоверений до разрешения трафика на развернутый сайт.

Этот модуль выполняет следующие операции для вашего приложения:This module handles several things for your app:

  • проверку подлинности пользователей с указанным поставщиком;Authenticates users with the specified provider
  • проверку, хранение и обновление токенов;Validates, stores, and refreshes tokens
  • управление сеансом с проверкой подлинности;Manages the authenticated session
  • вставка сведений об удостоверении в заголовки запросов.Injects identity information into request headers

Модуль работает отдельно от кода приложения и настраивается с помощью параметров приложения.The module runs separately from your application code and is configured using app settings. Для кода приложения не нужны пакеты SDK, определенные языки или изменения.No SDKs, specific languages, or changes to your application code are required.

Архитектура функций в Linux и контейнерахFeature architecture on Linux and containers

Модуль проверки подлинности и авторизации выполняется в отдельном контейнере, изолированном от кода приложения.The authentication and authorization module runs in a separate container, isolated from your application code. Используя то, что известно как шаблон посредник, он взаимодействует с входящим трафиком для выполнения аналогичных функций в Windows.Using what's known as the Ambassador pattern, it interacts with the incoming traffic to perform similar functionality as on Windows. Поскольку она не выполняется в процессе, прямая интеграция с конкретными языковыми платформами невозможна; Однако соответствующие сведения, необходимые вашему приложению, передаются с помощью заголовков запросов, как описано ниже.Because it does not run in-process, no direct integration with specific language frameworks is possible; however, the relevant information that your app needs is passed through using request headers as explained below.

Поток проверки подлинностиAuthentication flow

Поток проверки подлинности одинаков для всех поставщиков, но будет различным для разных способов входа в систему: с использованием пакета SDK поставщика или без.The authentication flow is the same for all providers, but differs depending on whether you want to sign in with the provider's SDK:

  • Без использования пакета SDK поставщика. Приложение делегирует федеративный вход в службу приложений.Without provider SDK: The application delegates federated sign-in to App Service. Обычно это относится к приложениям браузера, которые могут предоставить пользователю страницу входа поставщика.This is typically the case with browser apps, which can present the provider's login page to the user. Код сервера управляет процессом входа, поэтому он также называется управляемым сервером потоком или потоком сервера.The server code manages the sign-in process, so it is also called server-directed flow or server flow. Этот вариант применяется к браузерным приложениям.This case applies to browser apps. Он также относится к собственным приложениям, в которых вход пользователей в систему выполняется с помощью пакета SDK для клиента мобильных приложений. Пакет SDK открывает веб-представление, в котором пользователи выполняют вход с помощью проверки подлинности службы приложений.It also applies to native apps that sign users in using the Mobile Apps client SDK because the SDK opens a web view to sign users in with App Service authentication.
  • С использованием пакета SDK поставщика. Вход пользователей в приложение на странице поставщика выполняется вручную, а затем приложение отправляет маркер проверки подлинности в Службу приложений Azure для проверки.With provider SDK: The application signs users in to the provider manually and then submits the authentication token to App Service for validation. Обычно это относится к внебраузерным приложениям, которые не могут предоставить пользователю страницу входа в систему.This is typically the case with browser-less apps, which can't present the provider's sign-in page to the user. Код приложения управляет процессом входа, поэтому его также называют управляемым клиентом потоком или потоком клиента.The application code manages the sign-in process, so it is also called client-directed flow or client flow. Этот вариант применяется к REST API, Функциям Azure и клиентам браузера JavaScript, а также к браузерным приложениям, которым требуется больше гибкости при входе в систему.This case applies to REST APIs, Azure Functions, and JavaScript browser clients, as well as browser apps that need more flexibility in the sign-in process. Это также относится к собственным мобильным приложениям, в которых вход пользователей в систему выполняется с помощью пакета SDK поставщика.It also applies to native mobile apps that sign users in using the provider's SDK.

Вызовы из доверенного приложения браузера в службе приложений на другой REST API в службе приложений или в функции Azure могут проходить проверку подлинности с помощью управляемого сервером потока.Calls from a trusted browser app in App Service to another REST API in App Service or Azure Functions can be authenticated using the server-directed flow. Дополнительные сведения см. в статье Настройка проверки подлинности и авторизации в Службе приложений Azure.For more information, see Customize authentication and authorization in App Service.

В приведенной ниже таблице показаны шаги выполнения потока проверки подлинности.The table below shows the steps of the authentication flow.

ШагStep Без использования пакета SDK поставщикаWithout provider SDK С использованием пакета SDK поставщикаWith provider SDK
1. вход пользователя1. Sign user in Перенаправляет клиента к /.auth/login/<provider>.Redirects client to /.auth/login/<provider>. Код клиента выполняет вход пользователя непосредственно через пакет SDK поставщика и получает токен проверки подлинности.Client code signs user in directly with provider's SDK and receives an authentication token. Дополнительные сведения см. в документации поставщика.For information, see the provider's documentation.
2. После проверки подлинности2. Post-authentication Поставщик перенаправляет клиент к /.auth/login/<provider>/callback.Provider redirects client to /.auth/login/<provider>/callback. Клиентский код отправляет токен из поставщика в /.auth/login/<provider> для проверки.Client code posts token from provider to /.auth/login/<provider> for validation.
3. Установите сеанс с проверкой подлинности3. Establish authenticated session Служба приложений добавляет файлы cookie, прошедшие проверку подлинности, в ответ.App Service adds authenticated cookie to response. Служба приложений возвращает собственный токен проверки подлинности в код клиента.App Service returns its own authentication token to client code.
4. предоставление содержимого, прошедшего проверку подлинности4. Serve authenticated content Клиент включает файлы cookie, прошедшие проверку подлинности, в последующие запросы (автоматически обрабатываются браузером).Client includes authentication cookie in subsequent requests (automatically handled by browser). Код клиента предоставляет токен проверки подлинности в заголовке X-ZUMO-AUTH (автоматически обрабатывается пакетами SDK для клиента мобильных приложений).Client code presents authentication token in X-ZUMO-AUTH header (automatically handled by Mobile Apps client SDKs).

Для клиентских браузеров служба приложений может автоматически перенаправлять всех не прошедших проверку пользователей к /.auth/login/<provider>.For client browsers, App Service can automatically direct all unauthenticated users to /.auth/login/<provider>. Вы также можете отправить пользователям одну или несколько ссылок /.auth/login/<provider>, чтобы они вошли в ваше приложение с использованием поставщика по выбору.You can also present users with one or more /.auth/login/<provider> links to sign in to your app using their provider of choice.

Поведение авторизацииAuthorization behavior

В портал Azureможно настроить авторизацию службы приложений с помощью ряда поведений, если входящий запрос не прошел проверку подлинности.In the Azure portal, you can configure App Service authorization with a number of behaviors when incoming request is not authenticated.

Снимок экрана, показывающий раскрывающееся меню "действие, которое необходимо выполнить, если запрос не прошел проверку подлинности"

Ниже описаны возможные варианты.The following headings describe the options.

Разрешить анонимные запросы (без действий)Allow Anonymous requests (no action)

Этот параметр откладывает авторизацию трафика, не прошедшего проверку подлинности, в код приложения.This option defers authorization of unauthenticated traffic to your application code. Для запросов, прошедших проверку подлинности, служба приложений также передает сведения о проверке подлинности в заголовках HTTP.For authenticated requests, App Service also passes along authentication information in the HTTP headers.

Такой вариант обеспечивает большую гибкость в обработке анонимных запросов.This option provides more flexibility in handling anonymous requests. Например, он позволяет предоставлять пользователям несколько поставщиков входа.For example, it lets you present multiple sign-in providers to your users. Тем не менее необходимо написать код.However, you must write code.

Разрешить только запросы, прошедшие проверку подлинностиAllow only authenticated requests

Параметр используется для <provider> входа в систему.The option is Log in with <provider>. Служба приложений перенаправляет все анонимные запросы к /.auth/login/<provider> для выбранного вами поставщика.App Service redirects all anonymous requests to /.auth/login/<provider> for the provider you choose. Если анонимный запрос поступает из собственного мобильного приложения, возвращаемый ответ HTTP 401 Unauthorized.If the anonymous request comes from a native mobile app, the returned response is an HTTP 401 Unauthorized.

В этом случае в клиентском приложении не нужен код для проверки подлинности.With this option, you don't need to write any authentication code in your app. Более точная авторизация, например авторизация для конкретной роли, может выполняться путем проверки утверждений пользователя (см. раздел Access user claims (Доступ к утверждениям пользователя)).Finer authorization, such as role-specific authorization, can be handled by inspecting the user's claims (see Access user claims).

Внимание!

Таким образом, ограниченный доступ применяется ко всем вызовам приложения, что может быть нежелательно для приложений, которым требуется общедоступная Домашняя страница, как во многих одностраничных приложениях.Restricting access in this way applies to all calls to your app, which may not be desirable for apps wanting a publicly available home page, as in many single-page applications.

Примечание

По умолчанию любой пользователь в клиенте Azure AD может запросить маркер для вашего приложения из Azure AD.By default, any user in your Azure AD tenant can request a token for your application from Azure AD. Вы можете настроить приложение в Azure AD , если вы хотите ограничить доступ к приложению определенным набором пользователей.You can configure the application in Azure AD if you want to restrict access to your app to a defined set of users.

Утверждения пользователей и приложенийUser and Application claims

Для всех языковых платформ служба приложений делает утверждения в входящем токене (от пользователя, прошедшего проверку подлинности или клиентское приложение) доступным для кода путем их вставки в заголовки запроса.For all language frameworks, App Service makes the claims in the incoming token (whether that be from an authenticated end user or a client application) available to your code by injecting them into the request headers. Для приложений ASP.NET 4.6 служба приложений заполняет свойство ClaimsPrincipal.Current утверждениями пользователя, прошедшими проверку подлинности, поэтому вы можете следовать стандартным шаблонам кода .NET, включая атрибут [Authorize].For ASP.NET 4.6 apps, App Service populates ClaimsPrincipal.Current with the authenticated user's claims, so you can follow the standard .NET code pattern, including the [Authorize] attribute. Аналогичным образом для приложений PHP служба приложений заполняет переменную _SERVER['REMOTE_USER'].Similarly, for PHP apps, App Service populates the _SERVER['REMOTE_USER'] variable. Для приложений Java утверждения доступны в Tomcat сервлета.For Java apps, the claims are accessible from the Tomcat servlet.

Для функций Azure ClaimsPrincipal.Current не заполняется для кода .NET, но вы по-прежнему можете найти утверждения пользователя в заголовках запроса или получить ClaimsPrincipal объект из контекста запроса или даже через параметр привязки.For Azure Functions, ClaimsPrincipal.Current is not populated for .NET code, but you can still find the user claims in the request headers, or get the ClaimsPrincipal object from the request context or even through a binding parameter. Дополнительные сведения см. в разделе Работа с удостоверениями клиентов .See working with client identities for more information.

Дополнительные сведения см. в разделе Access user claims (Доступ к утверждениям пользователя).For more information, see Access user claims.

В настоящее время ASP.NET Core не поддерживает заполнение текущего пользователя с помощью функции проверки подлинности и авторизации.At this time, ASP.NET Core does not currently support populating the current user with the Authentication/Authorization feature. Однако для заполнения этого зазора существуют некоторые сторонние компоненты по промежуточного слоя с открытым кодом .However, some 3rd party, open source middleware components do exist to help fill this gap.

Хранилище токеновToken store

Служба приложений предоставляет встроенное хранилище токенов, которое представляет собой репозиторий токенов, связанных с пользователями ваших веб-приложений, API или собственных мобильных приложений.App Service provides a built-in token store, which is a repository of tokens that are associated with the users of your web apps, APIs, or native mobile apps. При включении проверки подлинности с помощью любого поставщика это хранилище токенов немедленно становится доступным для вашего приложения.When you enable authentication with any provider, this token store is immediately available to your app. Если для кода вашего приложения требуется доступ к данным из этих поставщиков от имени пользователя, чтобы:If your application code needs to access data from these providers on the user's behalf, such as:

  • опубликовать запись в ленте Facebook прошедшего проверку подлинности пользователя;post to the authenticated user's Facebook timeline
  • чтение корпоративных данных пользователя с помощью API Microsoft Graphread the user's corporate data using the Microsoft Graph API

Как правило, вам необходимо писать код для сбора, хранения и обновления этих токенов в своем приложении.You typically must write code to collect, store, and refresh these tokens in your application. В хранилище токенов при необходимости вы просто извлекаете токены и указываете службе приложений обновить их, если они становятся недопустимыми.With the token store, you just retrieve the tokens when you need them and tell App Service to refresh them when they become invalid.

Маркеры ID, маркеры доступа и маркеры обновления кэшируются для сеанса с проверкой подлинности и доступны только связанному пользователю.The ID tokens, access tokens, and refresh tokens are cached for the authenticated session, and they're accessible only by the associated user.

Если вам не нужно работать с токенами в приложении, хранилище токенов можно отключить на странице аутентификации и авторизации приложения.If you don't need to work with tokens in your app, you can disable the token store in your app's Authentication / Authorization page.

Ведение журнала и трассировкаLogging and tracing

Если вы включите ведение журнала приложений, вы увидите трассировку проверки подлинности и авторизации непосредственно в файлах журналов.If you enable application logging, you will see authentication and authorization traces directly in your log files. Если отображается сообщение об ошибке проверки подлинности, которое не ожидалось, вы можете найти все детали, просмотрев существующие журналы приложений.If you see an authentication error that you didn't expect, you can conveniently find all the details by looking in your existing application logs. Если вы включили трассировку неудачно завершенных запросов, вы можете точно определить, какую роль мог выполнять модуль проверки подлинности и авторизации в неудавшемся запросе.If you enable failed request tracing, you can see exactly what role the authentication and authorization module may have played in a failed request. Найдите ссылки на модуль с именем EasyAuthModule_32/64 в журналах трассировки.In the trace logs, look for references to a module named EasyAuthModule_32/64.

Дополнительные ресурсыMore resources

Примеры:Samples: